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ABSTRACT 


The  IGES  5.0  Recommended  Practices  Guide  is  intended  to  assist 
both  users  and  implementors  of  the  Initial  Graphics  Exchange 
Specification  (IGES)  Version  5.0.  It  contains  two  types  of 
information:  explanations  of  implementation  practices  that  are 
alternatives  to  those  documented  in  the  Specification,  including 
preferred  alternatives  where  preferences  exist,  and 
clarifications  of  ambiguities  or  omissions  in  the  Specification. 
Explanatory  Recommended  Practices  address  topics  such  as  the 
explanation  of  complex  areas  in  the  Specification,  testing 
methods,  processor  performance  considerations  and  the  mapping  of 
vendor  entities  into  the  set  of  IGES  entities.  Recommended 
Practices  that  clarify  an  ambiguity  or  omission  are  usually 
preludes  to  changes  in  the  Specification. 

The  Recommended  Practices  Committee  of  the  IGES/PDES  (Product 
Data  Exchange  using  STEP)  Organization  (IPO)  prepares  the 
Recommended  Practices  Guide.  Interested  users  and  implementors 
from  a variety  of  organizations  prepare  and  donate  material  for 
the  document.  Suggestions  for  future  topics  or  completed  forms 
which  propose  new  Recommended  Practices  (see  Appendix  A)  should 
be  sent  to  the  Chairman  of  the  Recommended  Practices  Committee 
in  care  of  the  IPO  Chairman,  National  Institute  of  Standards  and 
Technology,  Bldg.  220,  Rm.  A127,  Gaithersburg,  MD,  20899. 

The  IPO  Chairman's  Committee  has  reviewed  each  of  these 
Recommended  Practices  for  accuracy  and  acceptability  to  the 
general  IGES  community.  In  general,  while  preferred  technigues 
are  sometimes  offered,  no  individual  techniques  are  endorsed. 
The  final  choice  of  technique  can  be  made  only  in  conjunction 
with  the  details  of  the  environment  such  as  the  system,  the 
processor,  and  the  application. 
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INTRODUCTION 


The  Initial  Graphics  Exchange  Specification  (IGES)  Version  5.0 
document  specifies  the  structure  and  meaning  of  an  IGES  file.  It 
is  intended  to  be  a concise  explanation  of  the  IGES  file  and 
entity  formats  and,  in  general,  does  not  give  detailed 
explanations  of  the  underlying  concepts  or  of  the  reasoning 
behind  particular  choices  when  alternative  representations  are 
available. 

In  addition,  the  Specification  document  does  not  provide 
information  on  how  to  implement  translators  or  on  how  to  exchange 
data.  This  is  especially  a problem  when  decisions  must  be  made 
for  approximations.  The  Recommended  Practices  (RP)  Guide  is  a 
collection  of  practices  intended  to  help  write  translators.  It  is 
not  a cookbook  on  how  to  write  translators,  but  rather  a 
collection  of  implementation  issues  that  people  have  encountered. 
In  most  cases  the  practice  will  list  a suggested  solution.  In 
some  cases  there  is  no  suggested  solution  as  more  than  one  may  be 
equally  appropriate.  It  is  still  deemed  helpful  to  alert 
implementors  to  each  solution. 

The  Specification  and  RP  Guide  are  meant  to  complement  each 
other.  Since  RPs  can  be  handled  more  quickly  than  Requests  for 
Change  (RFCs)  , some  RFCs  will  be  preceded  by  an  RP.  It  is 
important  to  understand  that  RPs  are  NOT  part  of  the 
Specification,  but  are  guidelines;  therefore  compliance  with  them 
is  NOT  required. 

Sometimes,  an  RP  is  used  as  the  basis  for  an  RFC,  which 
ultimately  generates  an  Edit  Change  Order  (ECO)  to  the 
Specification.  When  this  happens,  the  corresponding  RP  becomes 
inoperative,  and  the  next  release  of  the  RP  guide  reflects  this 
fact;  the  RP  number  and  Problem  Statement  are  retained,  but  the 
other  sections,  tables,  and  illustrations  are  deleted. 


SUBMISSION  PROCEDURE 

This  section  explains  how  to  prepare  and  submit  a Proposed 
Recommended  Practice  (PRP)  as  well  as  the  process  a PRP  follows 
while  under  consideration  by  the  Recommended  Practices  Committee. 

Anyone  may  submit  a PRP.  Submissions  should  be  made  on  the  form 
provided  in  Appendix  A of  this  Guide.  Contents  should  conform  to 
the  following  format.  If  approved,  the  PRP  will  be  rewritten  to 
ensure  a uniform  standard  of  clarity  and  grammar. 
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Preparing  the  Form  for  a Proposed  Recommended  Practice 

PRP  Number:  The  PRP  number  and  revision  letter  are  assigned  by 
the  person  responsible  for  RP  change  control.  They  help  to  keep 
track  of  the  PRP  as  it  progresses  through  the  approval  process. 

Date:  Use  the  date  of  the  submission  of  the  PRP.  For  a 
revision,  use  the  date  that  the  revision  is  submitted  to  the  RP 
change  control  person. 

Number  of  Pages:  Include  the  number  of  pages  to  indicate  the 
total  length  of  the  complete  PRP. 

Author's  Name:  Fill  in  the  author's  name  and  address  so  that 
questions  and  discussion  can  be  directed  to  the  appropriate 
person. 


Affected  Processors:  Show  whether  the  PRP  applies  to 

preprocessors,  postprocessors,  both,  or  neither  (write  "none") . 


Category:  Indicate  which  of  the  following  standard  categories 

for  RPs  the  PRP  addresses. 


Software  Practice 
Conversion  Method 
Hierarchy  Rule 
Documentation 
Performance 
Testing  Method 


Implementation  Rationale 

Entity  Mapping 

Text 

Workaround 

IGES  Description 

Clarification 


Affected  Entities:  List  any  IGES  entities  affected  by  the  PRP. 
Use  both  the  name  and  the  entity  number. 


Keywords:  List  the  major  headings  under  which  the  PRP  should  be 
indexed.  The  RP  manual  includes  an  index  of  RPs  by  category  and 
by  keyword. 


Topic:  This  item  provides  a title  for  the  PRP.  It  should  be 
concise  without  being  cryptic. 

Body  of  PRP:  The  rest  of  the  PRP  is  the  most  important.  It 
should  be  written  to  maximize  the  reader's  understanding  of  the 
problem  and  of  the  proposed  solution.  The  body  should  contain 
the  following  headings: 


Problem  Statement 

Solution 

Rationale 

Alternatives  Considered 
Selected  Methodology 
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Problem  Statement:  The  Problem  Statement  section  should  contain 
a clear,  concise  description  of  the  problem  that  prompted  the 
PRP.  The  description  should  be  as  general  as  possible,  but 
should  use  examples  where  necessary  to  enhance  clarity. 

Solution:  The  Solution  section  should  contain  an  abstract  of  the 
recommended  solution  to  the  problem.  Give  a detailed  explanation 
with  examples  in  the  Rationale  section. 

Rationale:  The  Rationale  section  should  contain  an  explanation 
of  the  alternative  approaches  considered,  the  recommended 
solution,  and  the  reasons  for  selecting  the  recommended  solution. 
Use  examples  liberally.  The  subheadings  can  be  used  to  organize 
material  in  this  section. 

Alternatives  Considered:  The  Alternatives  Considered  section 
should  contain  a list  of  the  different  solutions  developed. 
Examples  aid  clarity  and  should  be  used  liberally.  In  addition 
to  explaining  the  different  alternatives,  include  a brief 
discussion  of  the  advantages  and  disadvantages  of  each 
alternative,  including  the  one  eventually  chosen. 

Selected  Methodology:  The  Selected  Methodology  should  contain 
the  chosen  alternative  and  an  explanation  of  why  it  was  selected. 
Justify  the  alternative  here,  and  explain  final  details  of  the 
solution. 


APPROVAL  PROCEDURE 

Completed  forms  which  propose  new  Recommended  Practices  (see 
Appendix  A)  should  be  sent  to  the  Chairman  of  the  Recommended 
Practices  Committee  in  care  of  the  IPO  Chairman,  National 
Institute  of  Standards  and  Technology,  Bldg.  220,  Rm.  A127, 
Gaithersburg,  MD,  20899.  The  PRP  will  be  distributed  and 
discussed  at  the  next  meeting  of  the  IGES  Recommended  Practices 
Committee. 

After  discussion  and  possible  modification,  the  Committee  will 
either  adopt  or  reject  the  PRP.  If  the  PRP  is  adopted,  it  will 
be  prepared  for  production  and  included  in  the  next  release  of 
the  Recommended  Practices  Guide. 

The  IGES  RFC  Review  Committee,  which  is  composed  of  the  chairmen 
of  the  various  IGES  technical  committees,  will  review  the  final 
version  of  each  release  of  the  Recommended  Practices  Guide  and 
approve  it  for  publication. 
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RP  l:  DELIMITER 


Category:  Software  Practice 
Keywords:  Parameter  Delimiter 


Affected  Processors:  Both 


IGES  Document  Version:  All 


Record  Delimiter 


Affected  Entities:  None 


Problem  Statement: 

Since  it  is  likely  that  certain  characters  will  be  used  to  convey 
relevant  information  in  the  parameter  data  section,  using  these 
symbols  for  either  delimiter  character  or  end  of  parameter 
character  will  cause  parsing  difficulties  in  the  postprocessor. 


{ This  RP  has  been  resolved  by  IGES  Version  4.0  > 
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RP  2:  WITNESS  LINE  SUPPRESSION 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Blank  Status 


Affected  Processors:  Pre 


Annotation 


Affected  Entities 


Directory  Entry 


Witness  Line 
(106,  form  40) 


Problem  statement: 

Witness  lines  used  in  annotation  entities  may  be  suppressed  by 
two  methods. 


Alternatives  Considered: 

Do  one  of  the  following  to  suppress  witness  lines: 

1.  Place  a 0 in  the  witness  line  pointer  field  of  the 
annotation  entity. 

2 . Set  the  blank  status  in  the  directory  entry  of  the 
copious  data  entity. 

Method  1 is  confusing  because  during  postprocessing  it  is 
impossible  to  determine  whether  the  annotation  entity  lacks 
witness  lines  entirely  or  has  blanked  witness  lines;  it  also 
prevents  the  IGES  file  from  communicating  the  parameterization  of 
blanked  witness  lines. 


Selected  Methodology: 

Method  2 should  be  used  whenever  a witness  line  exists  in  an 
annotation  entity,  whether  or  not  it  is  blanked.  Method  1 should 
be  used  only  if  the  witness  line  is  not  present  in  the  annotation 
entity. 
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RP  3:  TRANSFORMATIONS  OF  NESTED  SUBFIGURES 


Category:  Hierarchy  Rule 
Keywords:  Matrix  Processing 


Affected  Processors:  Both 


IGES  Document  Version:  All 


Directory  Entry 
Subfigure 


Affected  Entities 


Subfigure  Def.  (308) 
Subfigure  Inst.  (408) 


Problem  Statement: 

Before  placement  of  a Subfigure  Instance  during  IGES 
postprocessing,  any  defining  matrix  and  applied  scale  factors 
must  operate  on  each  entity.  Where  nesting  (subfigure  within 
subfigure)  is  used,  the  order  of  operations  for  scaling  and 
translating  must  be  consistent  between  preprocessors  and 
postprocessors.  The  explanation  in  the  Specification  is  not 
sufficiently  clear. 


{ This  RP  has  been  resolved  by  IGES  Version  4.0  } 
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RP  4S  TRANSFORMATION  MATRIX  PROCESSING 


Category:  Performance 
Keywords:  Identity  Matrix 


IGES  Document  Version:  All 


Affected  Processors:  Pre 


Directory  Entry 
Matrix  Processing 


Affected  Entities 


Transform.  Matrix  (124) 


Problem  Statement: 

The  identity  matrix  in  field  7 of  a DE  record  can  be  identified 
in  several  ways. 

Alternatives  Considered: 

1.  Use  a pointer  to  an  identity  matrix  (124) . 

2.  Use  the  "default"  value  of  0. 

Selected  Methodology: 

For  processing  efficiency,  it  is  preferable  to  use  a zero  in 
field  7 of  the  DE  rather  than  to  use  a pointer  to  an  identity 
matrix. 
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RP  5:  SYSTEM  ID  PARAMETER 


Category:  IGES  Description  IGES  Docximent  Version:  All 

Keywords:  Global  Parameter  5 Affected  Processors:  Pre 

System  ID  Affected  Entities:  None 

Global  Section 

Problem  Statement: 

Questions  have  arisen  concerning  the  contents  of  Global  Parameter 
5,  the  System  ID. 


{ This  RP  has  been  resolved  by  IGES  Version  4.0  } 
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RP  6:  MAGNETIC  TAPE  FORMAT 


Category:  Software  Practice 
Keywords:  Tape  Parity 
ASCII  Code 
Tape  Format 

Problem  Statement: 

There  is  no  standard  for  the 
media  such  as  magnetic  tape. 


IGES  Document  Version:  All 
Affected  Processors:  Both 
Affected  Entities:  None 


exchange  of  IGES  data  on  physical 


Alternatives  Considered: 

Media  to  be  used  for  data  transfer  should  be  agreed  upon  by  the 
sender  and  receiver  of  the  data.  Possible  methods  include 
magnetic  tape,  floppy  diskettes,  or  telecommunications. 


Selected  Methodology: 

Based  on  ANSI  X3. 39-1973  and  ANSI  X3. 22-1973,  use  magnetic  tape 
with  the  following  characteristics: 

o One-half  inch  tape 

o Unlabeled 

o 1600  BPI  density 

o 9 track 

o 7 bit  ASCII  code  (8th  bit  zero) 

o 80  character  fixed  length  records 

o 10  records  per  tape  block  (This  implies  a block  size  of 
800;  80  character  length  * 10  records) 
o A single  end  of  file  mark  separates  IGES  data  sets  on 
tape 

o Multiple  consecutive  end  of  file  marks  signal  the  end 
of  tape  data. 
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RP  7:  MAXIMUM  COORDINATE  VALUE 


Category:  Software  Practice 
Keywords:  Global  Parameter  20 

Max.  Coordinate  Value 
Global  Section 


IGES  Document  Version:  All 
Affected  Processors:  Pre 
Affected  Entities:  None 


Problem  Statement: 

The  preprocessor  sets  Global  Parameter  20  to  the  largest  value 
of  the  system,  not  to  the  largest  value  of  the  model. 


Selected  Methodology: 

If  possible,  evaluate  the  model  and  determine  the  actual  Maximum 
Coordinate  Magnitude  (MCM)  in  global  space.  Global  Parameter  20 
should  be  set  such  that: 

o any  |X,Y,Z|  < G20  and 

o |G20|  < 1.2  * MCM. 

If  the  MCM  is  not  calculated,  do  not  set  Global  Parameter  20  to 
the  maximum  size  of  any  model  of  the  system;  instead,  use  default 
parameter  (",,'*)• 
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RP  8:  XKDEPEMDENT  WITNESS  LINES 


Category;  Entity  Mapping 
Keywords;  Subord.  Entity  Switch 
DE  Level  Number 


I6ES  Dooument  Version;  All 

Affected  Processors;  Both 

Affected  Entities; 

Witness  Line 
(106,  form  40) 


Problem  Statement; 

Several  systems  have  native  database  data  structures  in  which  the 
dimension  witness  lines  are  not  linked  to  a "parent”  entity 
(e.g.,  linear  dimension,  angular  dimension).  The  IGES  data  files 
produced  from  these  systems  contain  copious  data  (form  40) 
witness  lines  which  are  "independent”  and  dimension  entities  with 
the  witness  line  pointers  equal  to  zero.  Conversely,  many  other 
systems  have  native  database  structures  in  which  the  "parent” 
entity  always  contains  the  references  to  witness  lines  and 
independent  witness  lines  are  not  allowed.  In  moving  an  IGES 
file  between  these  systems,  especially  from  the  former  to  the 
latter,  an  alternative  mapping  is  needed  to  retain  the  witness 
line. 


Selected  Methodology; 

Preprocessors  should  retain  the  "parent”  structure  whenever 
possible.  Postprocessors  for  receiving  systems  which  cannot 
support  "independent”  witness  lines  should  map  the  copious  data 
(106,  form  40)  to  corresponding  geometry  entities  (lines  and  arc 
segments) . These  entities  should  be  placed  on  a graphics  level 
(or  associated  with  special  attributes)  to  distinguish  them  from 
the  legitimate  model  geometry. 

An  unused  graphics  level  could  be  assigned  by  the  postprocessor, 
or  the  graphics  level  could  be  selected  by  the  user  when  the 
postprocessor  is  invoked.  In  either  case,  a message  should  be 
provided  indicating  the  attributes  which  distinguish  "witness 
line  geometry”  from  "model  geometry.”  If  independent  lines  are 
used,  the  entity  use  flag  should  be  set  to  "annotation.” 
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RP  9:  POSTPROCESSOR  DIAGNOSTICS 


Category:  Documentation 


IGES  Document  Version:  All 


Keywords:  Error  Message 


Affected  Processors:  Post 


Postprocessor 

Robustness 


Affected  Entities:  None 


Problem  Statement: 

IGES  postprocessors  often  discontinue  processing  after  an  error 
is  encountered  in  the  file,  and  do  not  provide  meaningful  error 
messages . 


Selected  Methodology: 

The  functions  of  an  IGES  postprocessor  are  similar  to  those  of 
a compiler.  The  postprocessor  should  recognize  errors 
encountered  when  an  IGES  file  is  processed,  should  provide  the 
user  with  an  indication  of  the  error,  and  should,  if  possible, 
continue  processing  the  file. 

The  key  elements  of  a diagnostic  capability  are: 

1.  Determine  Seriousness  of  Error.  The  postprocessor 
determines  the  impact  the  error  will  have  on  the 
processing  of  the  file,  and  categorizes  the  error. 
Possible  categories  include  FATAL  ERROR,  ERROR,  WARNING. 

2.  Continue  Processing  when  Possible.  After  an  error  is 
identified,  the  postprocessor  attempts  to  continue 
processing  the  file.  Many  errors  will  not  prevent 
processing,  and  multiple  errors  that  may  exist  will  need 
to  be  identified.  Options  can  be  included  to  stop 
processing  if  a fatal  error  occurs,  or  if  a specific 
number  of  errors  occur,  to  avoid  wasting  CPU  time  when 
a file  is  not  processable. 

3.  Provide  Meaningful  Error  Messages.  The  postprocessor 
provides  complete  error  messages  that  include  a 
description  of  the  error  and  the  location  of  the  error 
in  the  file.  The  postprocessor  also  should  provide  a 
summary  description  of  the  error  and  the  actions  taken, 
for  display  on  a terminal. 

The  following  i^  a list  of  some  common  errors.  This 
list  is  not  com  ate  but  contains  a variety  of  errors. 

After  each  error  message,  the  list  contains  a suggested 
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action.  The  processor  may  need  to  take  some  corrective 
action  before  continuing  after  non-fatal  errors.  Always 
output  some  type  of  message  to  the  user. 


POSSIBLE  ERROR 

SUGGESTED  ACTION 

Global  delimiters  in  error 

Tape  format — not  ASCII 

Binary  section  missing — binary 
format 

Terminate 

Terminate 

Terminate 

Entity  not  supported 

Global  version  not  supported 

Bypass  & continue 
Bypass  & continue 

No  end  of  record  delimiter 
Terminate  section  missing 

DE  section  missing 

Bypass  & continue 
Continue 

Terminate 

Sequence  field 

Out  of  order 

Missing 

Wrong  format 

Continue 

Continue 

Continue 

Parameters 

Wrong  type 

Invalid  value 

Use  default  & continue 

106 — (IP  parameter  not 
equal  to  1,2,3) 

Endpoints  not  on  circle/conic 
Pointers  not  in  DE  range 

Out  of  range 

Adjust  & continue 
Adjust  & continue 
Continue 

Continue 
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RP  10:  TEXT  FONT  0 


Category:  Text  IGES  Document  Version:  All 

Keywords:  Text  Font  Affected  Processor:  Both 

General  Note  Affected  Entities: 

General  Note  (212) 

Problem  Statement: 

Section  4.2.9  of  Version  2.0  of  IGES  states  that  "font  0 is  an 
old  symbol  font  and  should  no  longer  be  used."  At  the  same  time, 
one  of  the  philosophies  of  IGES  development  has  been  to  maintain 
upward  compatibility.  These  two  items  appear  to  conflict. 


Alternatives  Considered: 

1.  Eliminate  the  use  of  font  code  0 by  all  preprocessors 
and  postprocessors. 

2 . Support  the  acceptance  of  font  code  0 by  postprocessors 
only. 


Advantages/Disadvantages : 

Dis.  #1  Font  code  0 was  supported  in  version  1 of  the 
document.  Files  may  have  been  generated  that 
already  contain  font  code  0.  These  files 
would  no  longer  be  processable. 

Adv.  #2  Font  code  0 would  no  longer  be  generated,  but 
those  files  that  already  contain  font  code  0 
would  still  be  processable.  Further,  font 
code  0 could  eventually  be  removed  by 
processing  the  data  back  to  IGES. 


Selected  Methodology: 

Alternative  2 . 
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RP  11:  USER  INTERFACE 


Category:  Documentation 


IGES  Document  Version:  All 


Keywords:  Summary  Report 


Affected  Processors:  Both 


Information  Message 


Affected  Entities:  None 


Problem  Statement: 

Users  are  having  difficulty  determining  the  status  of  translators 
as  they  process  and  have  little  or  no  information  on  the  actions 
completed  by  a processor. 


Alternatives  Considered: 

The  basic  approach  is  to; 

1.  Provide  a mechanism  to  inform  the  user  that  processing 
is  continuing  in  a "normal"  fashion. 

2 . Provide  a summary  report  containing  the  entity  types 
and  counts  processed  at  completion. 

Item  1 can  be  addressed  in  an  interactive  session  by  sending  a 
message  to  the  workstation  after  each  "n"  entities  where  "n" 
could  be  1 to  10.  The  message  could  include  the  DE  pointer  to 
verify  that  a loop  situation  has  not  occurred.  Some 
implementations  currently  provide  no  clue  as  to  how  much  (or  how 
little)  conversion  has  been  completed. 

Item  2 can  be  addressed  by  generating  a summary  report  consisting 


of 


o translator  name  and  version 
o entities  input,  by  type  and  count 
o entities  output,  by  type  and  count 

o errors  encountered,  identified  by  entity  type,  count, 
condition,  and  DE  pointer 

o processing  time  (wall  and  CPU) 
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Selected  Methodology: 

The  items  listed  above  suggest  alternatives  to  solve  this 
problem.  The  decision  to  include  all  items,  a subset,  or  other 
indicators  is  left  to  the  discretion  of  the  implementor. 
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RP  12:  FLAG  NOTE  RESTRICTIONS 


Category:  IGES  Description  IGES  Document  Version:  All 

Keywords:  Flag  Note  Affected  Processors:  Pre 

Affected  Entities: 

Flag  Note  (208) 

Problem  Statement: 

A flag  note  with  multi-line  text  causes  problems  in  determining 
the  size  of  the  flag. 


{ This  RP  has  been  resolved  by  IGES  Version  4.0  } 
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RP  13:  VIEWS  FOR  TRANSFORMATIONS 


Category:  Software  Practice 
Keywords:  Extra  View 


Affected  Processors:  Post 


I6ES  Document  Version:  All 


Coordinate  System 
Matrix  Processing 


Affected  Entities 


Transform.  Matrix  (124) 


Problem  Statement: 

The  PDDI  Report*  found  that  several  postprocessors  create  a 
separate  view  for  each  transformation  matrix  resulting  in  a 
proliferation  of  views. 


Selected  Methodology: 

The  postprocessor  should  move  the  data  to  its  appropriate 
position  without  creating  a new  view.  This  is  even  more 
important  for  conics  since  the  transformation  matrix  is  always 
required  for  moving  conics  to  their  final  placement. 


* Product  Definition  Data  Interface,  Task  I - Evaluation  & 
Verification  of  ANSI  Y14.26M  Standard,  IGES  Committee 
Presentation  by  Booz,  Allen  & Hamilton  Inc.  October  18,  1983. 


18  IGES  5.0  Recommended  Practices  Guide  May  1991 


RP  14:  TRANSLATOR  DOCUMENTATION 


Category:  Documentation 


ICES  Docvunent  Version:  All 


Keywords:  Manual 


Affected  Processors:  Both 


Error  Message 


Affected  Entities:  None 


Information  Message 


Problem  Statement: 

The  PDDI  Report  identified  documentation  as  a problem. 
Selected  Methodology: 

The  following  is  the  minimum  set  of  documentation: 

1.  Formal  manuals: 

o Installation  and  execution  instructions 

o Translation  tables  including  entity  support,  mappings, 
approximations,  and  support  limitations 

o User  options 

o Error  messages  and  any  compensatory  action. 

2.  Translation  Messages: 
o Error  messages 

o Informative  messages 


EXAMPLES : 


A message  indicating  that  a particular  entity 
was  not  supported. 


A message  indicating  that  a font  was  not 
supported  and  another  was  substituted. 
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RP  15:  ZERO  RADIUS  ARCS 


Category:  Software  Practice 
Keywords:  Invalid  Data 


Affected  Processors:  Both 


I6ES  Document  Version:  All 


Circular  Arc 


Affected  Entities 


Circular  Arc  (100) 


Problem  Statement: 

Some  preprocessors  write  arcs  of  zero  radius.  This  can  occur 
for  two  reasons:  (1)  Either  the  user  put  a zero  radius  arc  in 
his  part,  or  (2)  the  magnitude  of  the  coordinates  of  the  center 
point  was  much  greater  than  the  radius  of  the  arc,  and  precision 
errors  caused  the  center  point  and  endpoints  of  the  arc  to  be 
coincident.  Of  these  two  possibilities,  it  appears  that 
precision  problems  are  not  nearly  as  common  as  user-generated 
zero  radius  arcs. 


Alternatives  Considered: 

1.  If  the  radius  and  center  point  of  an  arc  are  such  that 
the  radius  cannot  be  properly  represented  with  adequate 
precision,  then  the  preprocessor  should  define  the  arc 
with  its  center  at  the  origin,  and  use  a transformation 
matrix  to  move  the  arc  into  its  correct  position. 

2.  If  the  user  puts  a zero  radius  arc  in  his  part,  it  is 
invalid. 

3.  If  a zero  radius  arc  is  encountered  in  the  sending 
system's  data  base,  the  preprocessor  should  ignore  it. 

Alternatives  1 and  2 combined,  allow  the  maximum  amount  of 
information  to  be  transferred  via  the  Specification,  and  allow 
any  presently  existing  IGES  file  to  be  read.  Alternative  3 has 
the  advantage  that  the  entire  burden  is  placed  on  the 
preprocessor;  however  it  does  not  allow  for  the  transfer  of  zero 
radius  arcs.  Existing  files  which  contain  zero  radius  arcs  would 
not  necessarily  be  readable  under  this  proposal. 

Although  it  is  likely  that  zero  radius  arcs  represent  user  or 
system  error,  it  might  be  unwise  to  completely  disallow  their 
existence  in  IGES  files. 
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Selected  Methodology 


Preprocessor: 

Zero  radius  arcs  are  invalid  in  the  IGES  Specification 
(see  section  4.3,  Version  5.0)  and  should  not  be  written 
to  the  IGES  file  as  an  arc  entity.  An  appropriate 
message  should  be  issued. 

Postprocessor : 

If  a zero  radius  arc  is  encountered,  it  should  be 
skipped  and  an  appropriate  message  should  be  issued. 
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RP  16:  TRANSLATION  VECTOR 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Transformation  Matrix  Affected  Processors:  Post 


Matrix  Processing 


Affected  Entities 


Transform.  Matrix  (124) 


Problem  Statement: 

Postprocessor:  Some  systems  do  not  handle  translation  vectors. 
Those  systems  that  store  a rotation  matrix  as  part  of  the 
internal  entity  representation  incur  an  additional  processing 
burden  in  handling  translation  vectors. 


Alternatives  Considered: 

Use  of  the  translation  vector  in  preprocessing  into  the 
Specification  is  not  to  be  discouraged.  It  is  reasonable  to 
assume  that  any  preprocessor  making  use  of  this  feature  does  so 
with  justification.  Correct  postprocessing  of  IGES  data 
involving  a translation  vector  is  to  be  encouraged.  For 
receiving  systems  that  store  only  a rotation  matrix,  correct 
postprocessing  involves  a computational  overhead  of  a matrix 
multiplication  and  a vector  addition.  The  rotation  matrix  in 
the  IGES  data  remains  as  the  correct  rotation  matrix  in  the 
receiving  system.  This  is  not  considered  a burdensome  situation 
relative  to  the  alternative  position  of  recommending  that 
translation  vectors  not  be  inserted  in  the  IGES  data. 


Selected  Methodology: 

A procedure  for  postprocessing  IGES  data  containing  a translation 
vector  is  suggested. 


Rationale: 

Entity  data  expressed  in  the  Specification  which  utilizes  both 
a rotation  matrix  and  a translation  vector  is  of  the  form 


Rx  + V 


where  R is  the  3 by  3 rotation  matrix,  v is  the  translation 
vector,  and  x is  the  vector  of  definition  space  coordinates. 
For  systems  accommodating  only  a rotation  matrix,  the  origin  of 


22 


IGES  5.0  Recommended  Practices  Guide  May  1991 


definition  space  necessarily  coincides  with  the  origin  of  model 
space.  If  such  a system  is  to  postprocess  entity  data  of  the 
above  type,  for  which  the  origins  do  not  coincide,  the  definition 
space  coordinates  in  the  receiving  system  must  be  adjusted  to 
absorb  the  translation  vector. 

To  absorb  the  translation  vector,  the  quantity  Rx  + v must  be 
expressed  as  R(x  + u)  for  some  vector  u.  Then,  in  the  receiving 
system,  R is  still  the  rotation  matrix,  and  (x  + u)  is  the  vector 
of  definition  space  coordinates. 

The  vector  u is  R’V.  This  can  be  seen  from  the  following: 

Rx  + V = Rx  + RR’V  = R(X  + R"V)  = R(x  + U)  . 
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RP  17:  MODEL  SPACE  SCALE 


Category:  Software  Practice 


ICES  DocTiment  Version:  All 


Keywords:  Global  Parameter  13 


Affected  Processors:  Both 


Model  Space  Scale 


Affected  Entities:  None 


Global  Section 


Problem  Statement: 

Clarification  is  needed  on  the  interpretation  of  Model  Space 
Scale  fPDDI  Report,  pg.  93) . 


Selected  Methodology: 

Preprocessor; 

1.  If  the  model  in  the  CAD  system  is  a scaled  model  (e.g., 
quarter  scale) , the  preprocessor  should  assign  the 
following  values  for  Global  Parameter  i3 : 


Model  Coordinate 


Model  Space  Scale  = 


Real  World  Coordinate 


For  example,  for  a one-quarter  scale  model,  this  model 
space  scale  is  0.25.  Coordinate  values  assigned  by  the 
preprocessor  will  be  "model”  coordinates. 

2.  If  the  model  is  not  a scaled  model,  the  preprocessor 
should  assign  Global  Parameter  13  as  1.0.  Coordinate 
values  assigned  by  the  preprocessor  are  "real  world" 
coordinates . 

Postprocessor : 

1.  If  the  postprocessor  encounters  a Global  Parameter  13 
value  of  1.0,  coordinate  values  are  in  real  world 
coordinates. 

2.  If  the  postprocessor  encounters  a Global  Parameter  13 
that  is  not  equal  to  1.0,  the  postprocessor  should 
provide  the  user  with  two  options  and  inform  the  user 
of  the  option  taken. 
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Option  1:  Create  a scaled  model:  Coordinate  values  in  the 
IGES  file  are  model  coordinates  and  should  be  used 
directly. 

Option  2:  Create  a full  scale  model:  Coordinate  values  in 
the  IGES  files  should  be  divided  by  Global 
Parameter  13 . 

IGES  File  Coordinate 

Native  Coordinate  = 

Global  Parameter  13 

Note:  This  Recommended  Practice  applies  only  to  coordinate 

values.  It  does  not  apply  to  other  values  such  as  arrow  height 
or  text  box  height. 
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RP  18:  PROCESSING  MACRO  ENTITIES 


Category:  IGES  Description 


IGES  Document  Version:  All 


Keywords:  MACRO  PD  Parameter 


Affected  Processors:  Both 


Parameter  Data 


Affected  Entities 


MACRO  Definition  (306) 


MACRO  Instance 

(600-699  & 1000-9999) 


Problem  Statement: 

The  syntax  of  the  macros  is  considerably  different  from  anything 
else  in  the  Specification.  Specifically,  the  word  MACRO  in  the 
parameter  section  caused  some  processing  problems  (PDDI  Report, 
pg.  84) . 


{ This  RP  has  been  deleted  - its  content  contradicted  IGES  } 
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RP  19:  INDEPENDENT  AND  DEPENDENT  PROCESSING 


Category:  Hierarchy  Rule  IGES  Docxunent  Version:  All 

Keywords:  Subord.  Entity  Switch  Affected  Processors:  Both 
Directory  Entry  Affected  Entities:  None 

Problem  Statement: 

There  is  confusion  as  to  the  meaning  and  use  of  the  Subordinate 
Entity  Switch. 


Selected  Methodology: 

Physical  dependency  means  that  the  subordinate  entity  cannot 
exist  in  the  native  system  unless  the  superordinate  entity 
exists.  Logical  dependency  means  that  the  subordinate  entity 
can  exist  alone,  but  that  it  will  also  be  part  of  some  sort  of 
logical  grouping  in  the  native  database.  The  implications  of 
the  above  definition  are  as  follows: 

1.  The  matrix  pointed  to  by  the  logically  superordinate 
entity  has  no  effect  on  the  subordinate  entity's 
physical  location. 

2.  An  entity  cannot  be  physically  and  logically  dependent 
upon  the  same  superordinate  entity. 

3.  When  an  independent  entity  is  encountered,  it  should  be 
immediately  added  to  the  native  database. 

4.  When  a physically  dependent  entity  is  encountered,  it 
should  not  be  added  to  the  database,  since  it  cannot 
exist  alone.  It  will  be  processed  and  added  to  the 
database  when  its  physically  superordinate  entity  is 
processed. 

5.  When  a logically  dependent  entity  is  encountered,  it 
should  be  immediately  added  to  the  database  since  it 
can  stand  alone,  but  some  mechanism  should  be  devised 
so  that  when  the  logically  superordinate  entity  is 
processed,  the  logically  subordinate  entity  can  be 
located  in  the  native  database  and  have  the  logical 
connection  established. 


IGES  5.0  Recommended  Practices  Guide  May  1991 


27 


Below  are  several  examples. 


Subordinate  Entity 

witness  line 

conic 

line 

leader  line 
arc 


Superordinate  Entity 


Relationship 


linear  dimension 
subfigure  definition 
group  (402,  forms  1,  7, 
14  & 15) 

radial  dimension  and 
group 

subfigure  definition 
and  group 


physical 

physical 

logical 

physical 

logical 

physical 

logical 
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RP  20:  BACK  POINTERS  IN  VIEW  ASSOCIATIVITY 


Category:  IGES  Description 
Keywords:  View  Associativity 

Views  Visible  Assoc. 

(402,  forms  3 & 4) 


IGES  Docximent  Version:  All 
Affected  Processors:  Both 
Affected  Entities: 


Problem  Statement: 

The  Views  Visible  Associativities  (402,  forms  3 & 4)  can  be 
unnecessarily  complex  for  a preprocessor  to  build.  The  term 
"related  entities"  means  that  the  entities  are  to  be  associated 
with  all  the  views  pointed  to  by  the  View  Associativity.  The 
View  Associativity  points  to  the  related  entities  in  class  2 and 
the  related  entities  point  to  the  views  associativity  in  the  DE 
view  pointer  field. 


{ This  RP  has  been  resolved  by  IGES  Version  5.0} 
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RP  21:  COMMENTS  IN  PARAMETER  DATA  RECORDS 


Category:  Software  Practice 
Keywords:  Comment 


ICES  Document  Version:  All 
Affected  Processors:  Pre 
Affected  Entities:  All 


Problem  Statement: 

Comments  may  follow  the  end  of  record  delimiter  in  the  Parameter 
Data  (PD)  section.  Implementors  are  reminded  of  this  fact.  A 
postprocessor  should  be  able  to  bypass  any  comment  records  after 
the  last  PD  parameter  of  the  entity. 


Selected  Methodology: 

The  comment  field  starts  after  the  end  of  record  delimiter  and 
may  extend  for  several  records.  The  Directory  Entry  (DE)  back 
pointer  field,  section  code  ("P”) , and  sequence  number  are 
required  on  all  PD  records  including  comment  records.  The  DE 
field  14  (PD  line  count)  must  include  all  comment  records  in  the 
PD  section. 
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RP  22:  BOUNDED  PLANES 


Category:  Entity  Mapping 


ICES  Document  Version:  All 


Keywords:  Bounded  Plane 


Affected  Processors:  Post 


Bounding  Curve 


Affected  Entities 


Unbounded  Plane 


Plane  (108) 


Problem  Statement: 

Some  systems  that  do  not  support  bounded  planes  nevertheless 
postprocess  them  as  unbounded  planes.  In  such  cases  there  is  a 
danger  that  the  bounding  curve,  which  is  flagged  as  a subordinate 
entity,  may  not  be  postprocessed  and  that  this  information  will 
be  lost. 


{ This  RP  has  been  resolved  by  I6ES  Version  4.0  } 
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RP  23:  RULED  SURFACE  DISCONTINUITY 


Category:  Software  Practice 
Keywords:  Composite  Curve 


Affected  Processors:  Both 


ICES  Document  Version:  All 


Slope  Discontinuous 


Affected  Entities 


Composite  Curve  (102) 


Ruled  Surface  (118) 


Problem  statement: 

A ruled  surface  that  has  a slope  discontinuous  composite  curve 
as  one  of  its  defining  curves  will  have  a corresponding  slope 
discontinuity . 

Alternatives  Considered: 

1.  Disallow  use  of  a composite  curve  in  defining  a ruled 
surface. 

2.  Allow  use  of  a composite  curve  in  defining  a ruled  surface 
and  issue  an  appropriate  warning. 

Selected  Methodology: 

Alternative  2 
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RP  24:  REPRESENTATION  OF  LINEAR  STRINGS 


Category:  Entity  Mapping  IGES  Document  Version:  All 

Keywords:  Linear  Spline  Affected  Processors:  Both 

Circular  Arc  Affected  Entities: 

Circular  Arc  (100) 
Composite  Curve  (102) 
Copious  Data  (106) 

Line  (110) 

Parametric  Spline  (112) 
Parametric  Surface  (114) 
B-spline  Curve  (126) 
B-spline  Surface  (128) 


Problem  Statement: 

In  many  systems,  there  are  entities  represented  by  lines  and 
"spars'*  displayed  between  a series  of  coordinates.  These 
entities  have  no  one-to-one  counterpart  in  terms  of  naming 
conventions  in  the  IGES  Specification.  A common  definition  is 
proposed  so  that  different  vendors  can  successfully  transfer  this 
type  of  data  between  systems. 


Alternatives  Considered: 

1.  Use  the  Copious  Data  Entity  (106)  for  entities 
consisting  entirely  of  line  segments; 

Advantage:  Simple  to  define,  concise. 

Disadvantage:  Risks  encouraging  use  as  a catch-all  for 

anything  dealing  with  line  graphics. 

2.  Use  the  Composite  Curve  Entity  (102)  for  entities  which 
point  to  lines  and  circular  arcs  representing  each 
segment. 
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Advantage : 


Handles  mixtures  of  lines 
and  arcs. 


Disadvantage:  Complicated  structure. 


3.  Use  the  Rational  B-spline  Entity. 

Advantage:  The  definition  of  the  IGES  B-spline  Entity 

includes  a "class”  field  to  describe  it.  This 
is  the  closest  one-to-one  entity  corres- 
pondence not  in  the  catch-all  category. 

Disadvantage:  Creates  longer  entity  definitions  than  the 

first  two  alternatives. 


Selected  Methodology: 

Since  the  primary  disadvantage  of  alternative  3 is  longer 
processing  time  due  to  definition  length,  any  reasonable 
alternative  that  takes  considerably  less  processing  time  should 
be  selected.  Alternative  1 provides  a clear,  concise  definition 
in  a fraction  of  the  space  and  executes  in  a fraction  of  the  time 
taken  by  other  options. 

For  entities  consisting  entirely  of  line  segments,  use 
alternative  1.  For  entities  containing  circular  arcs  or  other 
curves,  use  alternative  2. 
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RP  253  MINIMUM  USER  INTENDED  RESOLUTION 


Category:  Performance 
Keywords:  Global  Parameter  19 
Minimum  Resolution 
Global  Section 


IGES  Document  Version:  All 
Affected  Processors:  Both 
Affected  Entities:  None 


Problem  Statement: 

There  is  confusion  as  to  the  proper  setting  and  use  of  Global 
Parameter  19  (Minimum  Intended  Resolution) . 


Alternatives  Considered: 

The  description  of  the  Minimum  User-intended  Resolution  (MUR)  in 
the  IGES  Specification,  Version  5.0,  states: 

This  parameter  indicates  the  smallest  distance  in  model 
space  units  that  the  system  should  consider  as 
discernible.  Coordinate  locations  in  the  file  which 
are  less  than  this  distance  apart  should  be  considered 
to  be  coincident. 

Coincident  point  testing  is  needed  for  identifying: 
o a circle  from  a small  arc 

o a valid  piecewise  continuous  composite  curve 
o a valid  unit  vector 

o a valid  line  length 

o valid  start  and  terminate  points  lying  on  a conic  or 
an  arc. 

o positional  continuity  requirements  implied  at  the 
interior  breakpoints  of  a Parametric  Spline  Curve 
Entity  (112) . A breakpoint  T(i)  is  on  an  interior 
breakpoint  if  l<i<n+l  where  the  breakpoints  of  the 
parametric  spline  curve  are  T(i) , ( i=l , . . . , n+1)  where 

the  parameter  H has  a value  of  0,  1 or  2.  Note  the 
coincident  point  tolerance  is  not  used  to  test  for 
the  slope  continuity  or  curvature  continuity. 
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When  testing  for  coincident  points,  two  testing  schemes  could  be 
used: 


1.  box  metric,  and 

2.  Euclidean  metric. 

The  box  metric  testing  scheme  considers  whether  a point  lies 
within  a box  (2-D  square  or  3-D  cube)  centered  on  another  point. 
The  sides  are  twice  the  value  of  the  MUR.  This  scheme  can 
produce  inconsistent  results  depending  on  the  orientation  of 
geometry.  An  example  of  this  is  a horizontal  line  and  a diagonal 
line,  both  with  a size  just  larger  than  the  MUR.  The  end  points 
of  the  horizontal  line  would  not  be  considered  coincident,  but 
the  end  points  of  the  diagonal  line  would  be  considered 
coincident. 

The  Euclidean  metric  testing  scheme  considers  whether  a point 
lies  within  a radius  (2-D  circle  or  3-D  sphere)  centered  on 
another  point.  This  scheme  produces  consistent  results 
independent  of  the  geometry *s  orientation.  The  expense  of  this 
scheme  is  that  it  involves  squaring  each  delta  coordinate,  which 
slows  down  processing  time. 

It  should  be  noted  that  some  IGES  processor  implementors  have  no 
control  over  the  coincident  point  testing  schemes  used  in  their 
system's  geometric  modelers. 


Selected  Methodology: 

One  coincident  point  scheme  should  be  used  throughout  the  IGES 
processor  and  its  geometric  modeler.  It  is  more  important  that 
the  preprocessor  and  postprocessor  use  the  same  method  than  which 
method  is  used.  When  both  systems  do  not  use  the  same  method, 
errors  may  occur. 

Each  processor  should  document  its  coincidence  testing  method  so 
users  will  be  aware  of  possible  critical  discrepancies. 
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RP  26:  ARROWHEAD  AND  LEADER  LINE  DATA 


Category:  Entity  Mapping 


IGES  Document  Version:  All 


Documentation 


Affected  Processors:  Both 


Keywords:  Leader  Line 


Affected  Entities 


Arrowhead 


Leader  (214) 


Witness  Line 
(106,  form  40) 


Problem  Statement: 

IGES  preprocessors  and  postprocessors  handle  leader  lines  and 
arrowheads  differently.  (PDDI  Report,  Task  1,  pg.  71) 


Selected  Methodology: 

Preprocessors  should  use  the  form  number  for  the  Entity  Type  214 
which  matches  the  native  arrowhead  within  a family.  If  the 
arrowhead  in  the  native  system  does  not  match  any  IGES  arrowhead, 
the  preprocessor  should  select  the  Type  214  form  number  which 
most  closely  matches.  The  user  should  be  informed,  either  in  the 
user  documentation  or  by  means  of  a warning  message,  of  the 
action  taken. 

Postprocessors  should  select  the  native  arrowhead  that  matches 
the  IGES  arrowhead  identified  by  the  Type  214  form  number.  If 
the  system  does  not  have  an  arrowhead  that  exactly  matches  the 
IGES  arrowhead,  it  should  select  a native  arrowhead  that  most 
closely  matches  the  IGES  arrowhead.  The  user  should  be  informed, 
either  in  the  user  documentation  or  by  means  of  a warning 
message,  of  the  action  taken. 


Family 


Form  # 


triangular 
circular 
rectangular ' 
line 


1,2,3,11 

5,6,12 

7,8 

9,10 
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RP  27:  LIMITATIONS  ON  LEVEL  IDENTIFIERS 


Category:  Entity  Mapping 
Keywords:  DE  Level  Number 


I6ES  Document  Version:  All 
Affected  Processors:  Both 
Affected  Entities:  All 


Problem  Statement: 

Levels  allowed  on  each  system  vary  from  1 to  xxx  depending  upon 
the  vendor.  Consequently,  levels  in  excess  of  the  maximum  need 
a consistent  way  of  being  processed. 


Alternatives  Considered: 

A variety  of  mapping  methods  have  been  proposed  or  are  in  use. 

They  are  examined  below. 

1.  Wraparound.  Entities  on  layer  x are  mapped  to  layer  y 
where  y = MOD( (x  - k) , (Ns  + 1 - k) ) + k where  k is  the 
lowest  level  and  Ns  is  the  number  of  supported  levels 
on  the  receiving  system. 

2.  Fill  empty  levels.  A search  is  performed  for  levels 
whose  number  is  less  than  or  equal  to  Ns  and  which  have 
entities  assigned;  assume  Ne  entity  levels  are  found. 

The  first  Ne  levels  on  which  entities  are  defined  out- 
of-range  are  mapped  to  the  empty  levels.  Remaining  out- 
of-range  levels  are  mapped  by  alternative  1. 

3.  Use  nearest  level.  Out-of-range  levels  are  mapped  to 
the  highest  and  lowest  supported  levels,  respectively. 

4.  User  defined.  The  user  explicitly  specifies  the  mapping 
relationship  between  levels  by  creating  or  referring  to 
a mapping  table. 


Selected  Methodology: 

It  is  suggested  that  the  user  be  given  the  capability  of  choosing 
from  options  1 to  4,  the  default  method  being  wraparound.  The 
postprocessor  should  inform  the  user  of  the  mapping  relationship 
it  has  applied. 
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RP  28:  SINGLE/DOUBLE  PASS  PROCESSING 


Category:  Software  Practice 
Keywords:  Multiple  Pass 


Affected  Processors:  Post 


IGES  Document  Version:  All 


Single  Pass 


Affected  Entities:  All 


Problem  Statement: 

Is  it  more  appropriate  to  process  an  IGES  file  with  a single  or 
multiple  pass  approach?  The  concern  is  whether  a single-pass 
postprocessor  can  completely  process  all  of  the  data. 

Selected  Methodology: 

To  preserve  functionality,  a postprocessor  cannot  process 
structure  in  a single  pass.  Therefore,  multiple  passes  are 
recommended . 
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RP  29:  SPLINE  CURVES  AND  SURFACES 


Category:  Entity  Mapping 


I6ES  Dociiment  Version:  All 


Keywords:  Spline  Curve 


Affected  Processors:  Pre 


Spline  Surface 


Affected  Entities 


Parametric  Spline  (112) 
Parametric  Surface  (114) 
B-spline  Curve  (126) 
B-spline  Surface  (128) 


Problem  Statement: 

Parametric  Spline  Curve  and  Surface  Entities  need  to  be  enhanced 
so  (1)  they  may  reside  in  an  arbitrary  dimensional  image  space, 
and  (2)  their  underlying  polynomials  may  be  of  arbitrary  degree. 


Alternatives  Considered: 

1.  Extend  and  enhance  the  Parametric  Spline  Curve  and 

Surface  Entities  (112,  114). 

2.  Extend  and  enhance  the  Rational  B-spline  Curve  and 

Surface  Entities  (126,  128) , while  providing  algorithms 
to  convert  between  Parametric  Spline  and  Rational  B- 

spline  Curve  and  Surface  Entities  of  arbitrary 

dimensionality  and  degree. 


Selected  Methodology: 

Use  Rational  B-spline  Entities  (126,  128)  instead  of  Parametric 

Spline  Entities  (112,  114)  unless  considerations  dictate 

otherwise. 

Rationale: 

1.  Parametric  Spline  Curve  and  Surface  Entities  (112,  114) 
can  be  fully  captured  without  approximation  by  the 
Rational  B-spline  Curve  and  Surface  Entities  (126,  128) 
which  are  more  general . 

2.  To  avoid  redundancy,  Ent  -y  Types  112  and  114  will  be 
corrected  but  nc":  enhance  . All  enhancements  will  occur 
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within  the  context  of  the  Rational  B-spline  Entities 
(126,  128). 

3 . Coded  procedures  are  available  from  the  National 

Institute  of  Standards  and  Technology.  These  procedures 
translate  between  arbitrary  dimensional,  arbitrary 
degree,  rational  spline  curves  and  surfaces  defined  by 
Parametric  Spline  Entities  (112,  114)  and  Rational  B- 

spline  Entities  (126,  128) . 

These  procedures  enable  those  with  implementations  in 
their  native  databases  of  parametric  spline-like 
entities  to  use  IGES  Rational  B-spline  Entities  (126, 
128)  . 

4.  Rational  B-spline  Entities  already  allow  for  polynomials 
of  arbitrary  degree  and  will  be  enhanced  to  allow  for 
multi-dimensional  image  spaces. 
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RP  30:  GLOBAL  PARAMETER  DEFAULTS 


Category:  Software  Practice 
Keywords:  Global  Parameter 
Default  Value 
Required  Parameter 


IGES  Document  Version:  All 
Affected  Processors:  Both 
Affected  Entities:  None 


Problem  Statement: 

There  is  a great  deal  of  confusion  and  inconsistency  in  assigning 
default  values  for  parameters  in  the  Global  Section  of  an  IGES 
file.  There  are  also  diverse  opinions  on  which  of  the  parameters 
are  required.  This  Recommended  Practice  will  show  which 
parameters  are  required,  and  the  default  value  which  may  be 
assumed  for  each  parameter  that  is  not  required. 


Selected  Methodology: 

The  table  on  the  following  page  shows,  for  each  parameter  in  the 
Global  Section,  whether  the  parameter  is  required,  and  if  not 
required,  the  default  value  to  be  assumed.  This  table  should  be 
used  by  preprocessors  in  determining  which  values  to  include,  and 
whether  the  assumed  default  values  are  appropriate.  The  table 
should  be  used  by  postprocessors  in  determining  which  default 
values  to  assume  in  the  absence  of  a parameter  value.  If  a 
required  parameter  is  not  supplied,  the  postprocessor  may  have  to 
abort  its  processing,  depending  on  the  critical  nature  of  the 
data. 
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Global  Pareuneter 


Required  Default  Value 


1. 

Parameter  Delimiter 

no 

If  II 

! 

2. 

Record  Delimiter 

no 

11  . II 

t 

3. 

Product  ID  from  Sender 

yes 

none 

4. 

File  Name 

(1) 

none 

5. 

System  ID 

yes 

none 

6 . 

Translator  Version 

yes 

none 

7. 

No.  Bits  for  Integer 

yes 

none 

8. 

Single  Precision  Magnitude 

yes 

none 

9. 

Single  Precision  Significance 

yes 

none 

10. 

Double  Precision  Magnitude 

(2) 

none 

11. 

Double  Precision  Significance 

(2) 

none 

12. 

Product  ID  for  Receiver 

no 

GP3 

13. 

Model  Space  Scale 

no 

1.0 

14. 

Unit  Flag 

yes 

none 

15. 

Unit  Description 

(3) 

(4) 

16. 

Max.  Number  of  Line  Weights 

(5) 

1 

17. 

Size  of  Max.  Line  Width 

no 

0.0 

18. 

Date/Time  File  Generated 

yes 

none 

19. 

Min.  User  Intended  Resolution 

yes 

none 

20. 

Approx.  Max.  Coordinate  Value 

no 

none 

21. 

Name  of  Author 

no 

none 

22. 

Organization 

no 

none 

23. 

IGES  Version 

no 

3 

24. 

Applicable  Drafting  Standard 

no 

0 

25. 

Date/Time  Model  Created 

no 

none 

(1)  Required  if  External  Reference  used 

(2)  Required  if  double  precision  used 

(3)  Required  if  GP14  = 3 

(4)  String  appropriate  for  GP14 

(5)  Required  if  line  weight  is  significant 

Table  Item  Description: 

The  information  contained  in  the  above  table  is  the  result  of 
many  hours  of  discussion.  In  the  paragraphs  which  follow,  each 
parameter  will  be  defined  and  discussion  will  be  presented  of 
either  the  need  for  the  parameter  or  the  reasons  behind  the 
default  value  chosen. 

1.  Parauneter  Delimiter.  This  parameter  defines  the 
character  to  be  used  to  separate  parameters  in  a list 
in  a free  format  record  (i.e.,  in  the  Global  and 
Parameter  Data  Sections) . It  is  not  required,  and  its 
default  value  is  established  by  the  IGES  document  as 
the  string  (**1H,,''). 
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2. 


Record  Delimiter.  This  parameter  defines  the  character 
to  be  used  to  signify  the  end  of  a parameter  list  in 
free  format  records  (l.e.,  in  the  Global  and  Parameter 
Data  Sections)  . It  is  not  required,  and  its  default 
value  is  established  by  the  IGES  document  as  the  semi- 
colon ("IH;,”). 

3:  Product  ID  from  Sender.  This  parameter  contains  the 

name  of  the  model  identifier  (e.g.,  part  name  or 
number)  on  the  sender's  system  which  contains  the  model 
described  in  this  IGES  file. 

4:  File  Neime.  This  parameter  contains  the  name  of  the 

data  file  on  the  sending  system  which  contains  this 
IGES  file.  It  is  not  always  used  by  the  receiving 
system,  and  is  required  only  when  the  IGES  file  will  be 
the  object  of  an  external  reference. 

5:  System  Identification.  This  parameter  contains  the 

vendor's  name  and  model  designation  for  the  sending 
system.  This  information  is  required.  The  sender's 
system  identification  can  be  very  useful  in  determining 
how  to  handle  error  conditions  if  they  occur  during  the 
processing. 

6:  Translator  Version.  This  parameter  consists  of  the 

version  number  of  the  vendor's  IGES  preprocessor  used 
to  create  this  IGES  file,  and  is  required.  Like  the 
system  identification,  it  can  be  useful  in  determining 
how  to  handle  processing  errors. 

7:  N^omber  of  Bits  Used  to  Represent  Integer  Values.  This 

pirameter  is  required. 


8-11: 

Floating  Point  Values  Range.  Parameters  8 and  10  are 
powers  of  10  which  represent  the  maximum  value. 
Parameters  9 and  11  are  the  number  of  decimal  digits  of 
significance  which  can  be  actually  represented  on  the 
sending  system.  Parameters  8 and  9 are  always  required 
and  parameters  10  and  11  are  required  if  double 
precision  numbers  are  included  in  the  file. 

12:  Product  Identification  for  Receiver.  This  parameter 

can  provide  a receiver's  product  ID  (e.g.,  part  name  or 
number) . It  is  not  required,  and  if  not  present,  the 
contents  of  Parameter  3 (Product  ID  from  Sender)  may  be 
used. 

13:  Model  Space  Scale.  This  parameter  defines  the  ratio 

between  the  size  of  items  in  the  IGES  file  and  the  full 
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size  of  the  physical  object.  It  is  not  required,  and 
if  not  present,  is  assumed  to  be  1.0. 

14:  Unit  Flag.  This  parameter,  along  with  Parameter  15, 
identifies  the  units  used  in  creating  the  file.  A value 
for  this  parameter  is  required. 

15:  Unit  Description.  This  parameter  gives  a string 
equivalent  of  the  units  specified  by  Parameter  14.  It 
is  only  required  when  Parameter  14  has  a value  of  3 . 
If,  in  the  other  cases,  no  value  is  present,  the 
postprocessor  may  assume  the  string  which  corresponds 
to  the  value  of  Parameter  14. 

16:  Maucimum  Number  of  Line  Weights.  This  defines  how  many 
different  line  weights  are  used  in  the  IGES  file.  In 
many  cases,  there  is  no  significance  to  line  weights 
and,  therefore,  the  value  for  the  parameter  is  not 
required.  If  this  parameter  is  not  specified,  a value 
of  1 is  assumed. 

17:  Size  of  Meiximum  Line  Width.  This  parameter  defines  the 
width  of  the  widest  line  used  in  the  IGES  file.  It  is 
required  only  if  the  value  for  Parameter  16  is  present. 
Further,  a value  of  0 here  means  to  interpret  the  line 
weight  parameter  as  a relative  number.  The  relative 
line  weights  are  useful  on  a system  which  strokes  lines: 
a line  weight  of  3 indicates  that  3 standard  lines  are 
to  be  drawn  side  by  side  to  make  the  final  line.  This 
is  not  to  be  used  in  lieu  of  the  line-widening  property. 

18:  Date  and  Time  of  Exchange  File  Generation.  This  is  the 
date  and  time  that  the  preprocessor  created  the  IGES 
file.  It  is  required  to  help  uniquely  identify  the  IGES 
file  both  on  the  sending  and  receiving  systems. 

19:  Minimxim  User  Intended  Resolution.  This  parameter 
defines  the  intended  accuracy  of  the  model.  It  is 
required.  See  RP  25. 

20:  Approximate  Maximum  Coordinate  Value.  This  value 
indicates  the  size  of  the  model  to  the  postprocessor. 
This  information  is  necessary  on  some  systems  which  have 
to  set  a scaling  factor  for  the  model  before  the 
postprocessing  can  begin.  If  a reasonable  value  cannot 
be  placed  in  this  parameter  by  the  preprocessor,  it  is 
better  to  indicate  that  a default  value  is  to  be  used 
for  the  parameter  than  to  use  an  arbitrarily 

large  (but  unreasonable)  value.  If  the  default 
indication  is  used,  then  the  postprocessor  is 
responsible  for  determining  the  necessary  value.  See 
RP  7. 
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21: 


Name  of  Author.  This  information  is  strictly  for 
documentation  purposes.  Its  value  to  the  receiving 
system  depends  on  the  contractual  arrangements  made 
between  the  sending  and  receiving  organizations.  It  is 
not  required  and  no  default  value  is  defined. 

22:  Organization.  This  information  is  strictly  for 
documentation  purposes.  Its  value  to  the  receiving 
system  depends  on  the  contractual  arrangements  made 
between  the  sending  and  receiving  organizations.  It  is 
not  required  and  no  default  value  is  defined. 

23:  I6ES  Version.  This  parameter  tells  the  postprocessor 
which  version  of  the  IGES  specification  was  used  to 
generate  the  file.  The  information  is  useful  to  the 
postprocessor  for  determining  whether  or  not  it  may  run 
into  data  forms  or  IGES  features  which  it  cannot  handle. 
For  reasons  of  upward  compatibility,  this  parameter  is 
not  required.  If  not  present,  the  postprocessor  may 
assume  that  the  Version  2.0  Specification  (parameter 
value  of  3)  is  indicated. 

24:  Applicable  Drafting  Standard.  This  information 

indicates  that  the  creator  of  the  model  in  the  IGES  file 
complied  with  a specific  drafting  standard  while 
creating  that  model.  The  postprocessor  will  probably 
not  modify  any  of  its  processing  based  on  this 
parameter,  but  the  information  may  be  useful  to  the 
receiving  system  in  ensuring  that  drafting  entities 
added  to  the  postprocessed  model  will  comply  with  the 
same  standard.  The  parameter  is  not  required,  and  its 
default  value  is  0 (no  standard  specified) . 

25.  Date/Time  Model  Created/Modified.  Time  model  created 
or  modified,  whichever  occurred  last.  Preprocessors 
may  use  the  default  (**,/")  if  unknown.  (V.5.0) 
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RP  31:  HIERARCHY  FLAG 


Category:  Hierarchy  Rule 
Keywords:  DE  Hierarchy  Flag 


Affected  Processors:  Pre 


IGES  Document  Version:  All 


Directory  Entry 


Affected  Entities:  All 


Problem  Statement: 

Use  of  the  Hierarchy  Flag  on  an  entity-by-entity  basis  is 
unclear.  The  Hierarchy  Flag  set  to  0 in  the  view,  drawing,  or 
group  could  cause  a postprocessor  to  ignore  the  line  font,  level 
number,  view  pointer,  blank  status,  line  width  and  pen  number  in 
all  entities  within  a view,  drawing  or  group. 


Selected  Methodology: 


( This  RP  has  been  resolved  by  IGES  Version  5.0  ) 
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RP  32:  ARROVI  AND  WITNESS  POINTERS 


Category:  Software  Practice  IGES  Document  Version:  All 

Keywords:  Witness  Line  Affected  Processors:  Pre 

Arrowhead  Affected  Entities: 

Angular  Dim.  (202) 
Linear  Dim.  (216) 


Problem  Statement: 

Dimension  entiti  often  contain  two  (2)  leader/arrow  entity 
pointers  and  twc  2)  witness  line  entity  pointers.  They  are 
usually  referred  o as  ARWl,  ARW2,  WITl,  and  WIT2 . One  would 
normally  assume  that  ARWl  corresponds  to  WITl,  etc.,  and  some 
postprocessors  measure  the  distance  from  the  head  point  of  the 
arrow  to  the  end  point  of  the  witness  line  to  calculate  an 
"overshoot"  for  their  internal  database  representation. 

There  is  no  requirement  in  IGES  that  this  assumed  relationship 
be  maintained  by  the  preprocessor.  This  information  can,  in 
fact,  be  established  by  computational  examination;  however,  this 
places  a needless  burden  on  the  postprocessor. 


Selected  Methodology: 

The  preprocessor  should  support  the  assumed  relationship  when 
writing  an  IGES  file. 
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RP  33:  ENTITY  ORIGINS 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Transformation  Matrix  Affected  Processors:  Pre 


Entity  Origin 
Identity  Matrix 


Affected  Entities 


General  Note  (212) 


Text  Display  (312) 
Subfigure  Inst.  (408) 
View  (410) 


Problem  Statement: 

There  is  a problem  in  processing  the  General  Note  (212)  and 
Singular  Subfigure  Instance  (408)  Entities.  These  entities 
contain  explicit  "origin”  fields  in  their  Parameter  Data. 
However,  any  entity  can  be  repositioned  by  providing  a 
translation  vector  in  an  associated  Transformation  Matrix  (124) . 

Some  preprocessors  set  the  Parameter  Data  for  the  origin  to 
(0,0,0),  and  associate  a Transformation  Matrix  Entity  with  the 
identity  rotation  matrix  and  a (X,Y,Z)  translation  to  locate  the 
entity.  Some  "simplistic”  postprocessors  are  not  designed  to 
look  for  an  associated  translation,  and  consequently  misplace  the 
entity. 

Worse,  some  preprocessors  place  the  (X,Y,Z)  in  both  the  Parameter 
Data  section  and  a Transformation  Matrix;  the  corresponding 
postprocessor  obviously  ignores  one  of  the  values,  but  other 
postprocessors  misplace  the  entity.  Since  both  must  be  applied, 
the  data  should  not  be  duplicated;  this  practice  is,  in  fact, 
incorrect. 

The  problem  also  applies  to  the  Text  Display  Template  (312) , and 
the  View  (410),  which  has  an  (X,Y)  translation  in  the  parent 
Drawing  (404) . In  fact,  this  practice  can  be  generalized  to  any 
current  and  future  entities  which  contain  an  explicit  origin  in 
their  Parameter  Data  section. 


IGES  5.0  Recommended  Practices  Guide  May  1991 


49 


Selected  Methodology 


The  preprocessor  should  place  the  entity's  origin  in  the 
appropriate  field  of  the  Parameter  Data  section,  and  set  the 
translation  vector  in  any  associated  Transformation  Matrix  (124) 
to  (0,0,0) . 

However,  there  are  legitimate  reasons  for  valid  data  to  be 
contained  in  both  places,  so  all  postprocessors  must  be  prepared 
to  handle  combined  situations. 
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RP  34:  TEXT  ROTATION  ANGLE 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Transformation  Matrix  Affected  Processors:  Pre 


Rotation  Angles 


Affected  Entities 


General  Note  (212) 


Text  Display  (312) 


Problem  Statement: 

There  is  a problem  in  processing  the  General  Note  Entity  (212) . 
This  entity  contains  explicit  "rotation  angle"  and  "mirror" 
fields  in  its  Parameter  Data.  However,  any  entity  can  be 
reoriented  by  providing  a rotation  matrix  in  an  associated 
Transformation  Matrix  (124) . 

Some  preprocessors  set  the  Parameter  Data  for  the  rotation  to 
zero,  and  associate  a Transformation  Matrix  Entity  with  the 
desired  rotation  matrix  and  a (0,0,0)  translation  to  locate  the 
entity.  Some  "simplistic"  postprocessors  are  not  designed  to 
look  for  an  associated  rotation,  and  consequently  misplace  the 
entity. 

The  problem  also  applies  to  the  Text  Display  Template  (312) . In 
fact,  this  practice  can  be  generalized  to  any  current  and  future 
entities  which  contain  an  explicit  rotation  angle  in  their 
parameter  data. 


Selected  Methodology: 

The  preprocessor  should  place  the  entity's  rotation  in  the 
appropriate  field  of  the  Parameter  Data  section. 

However,  there  are  legitimate  reasons  for  valid  data  to  be 
contained  in  both  places,  so  all  postprocessors  must  be  prepared 
to  handle  combined  situations. 
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RP  35:  DUPLICATE  TRl^SFORHATION  MATRICES 


Category:  Software  Practice 


ICES  Document  Version:  All 


Keywords:  Transformation  Matrix  Affected  Processors:  Pre 


Entity  Origin 


Affected  Entities 


Rotation  Angles 


Transform.  Matrix  (124) 


Problem  Statement: 

Some  preprocessors  associate  a Transformation  Matrix  (124)  with 
every  Circular  Arc  (100)  even  when  they  contain  identical  data. 

For  example,  holes  on  a flat  surface  have  a common  normal  vector, 
but  the  preprocessor  gives  each  circle  its  own  (identical)  124 
instead  of  pointing  at  a common  one.  Another  problem  is  that  the 
preprocessor  may  set  the  origin  in  the  Parameter  Data  section  to 
(0,0)  and  generate  124s  with  identical  rotation  matrices  but 
unique  translation  vectors. 

In  a slightly  different  vein,  some  preprocessors  create  Circular 
Arc  entities  such  that  the  start  angle  is  always  zero  (Y2=Y1) , 
and  create  a Transformation  Matrix  which  rotates  it  into 
position.  In  the  case  of  the  filleted  corners  of  a cut-out  on  a 
planar  surface,  they  could  all  use  the  same  Transformation  Matrix 
if  their  start  and  end  points  are  adjusted. 

Either  of  these  implementations  leads  to  needlessly  large  IGES 
files,  and  places  a processing  burden  on  the  postprocessors. 

Although  the  circular  arc  is  used  to  illustrate  the  problem  it 
also  occurs  in  matrices  associated  with  Subfigure  Instances 
(408) , dimension  entities  (200  series) , and  other  geometric 
entities . 


Selected  Methodology: 

The  preprocessor  should  keep  track  of  the  Transformation  Matrices 
it  has  generated  and  point  to  them  instead  of  creating  new  ones. 

However,  there  are  legitimate  reasons  for  creating  matrices  with 
a common  normal  vector;  Conic  Arc  Entities  (104)  on  the  same 
plane  but  with  different  rotation  angles  are  one  example. 
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RP  36:  EXCESS  CHARACTERS  IN  REAL  NUMBERS 


Category:  Software  Practice  IGES  Docvunent  Version:  All 

Keywords:  Nuinber  Format  Affected  Processors:  Pre 

Affected  Entities:  All 


Problem  Statement: 

Some  preprocessors  output  real  numbers  in  a fixed-length  format 
which  takes  up  a lot  of  space;  in  some  cases,  only  two  (2)  real 
numbers  can  be  placed  on  a line  in  the  Parameter  Data  record. 


Selected  Methodology: 

Preprocessors  should  use  the  following  techniques  to  reduce  the 
length  of  text-string  representations  of  real  numbers  in  the 
Parameter  Data  record. 

1.  Delete  leading  blanks. 

2.  Delete  trailing  zeroes. 

3 . Round  coordinate  values  to  Global  Parameter 
19  (Minimum  User-Intended  Resolution) . 
Coefficients  should  not  be  rounded. 

4.  Avoid  unnecessary  use  of  scientific  notation. 
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RP  37:  REDUCE  I/O  OVERHEAD 


Category:  Software  Practice 
Keywords:  Thrashing 


IGES  DocTiment  Version:  All 
Affected  Processors:  Post 
Affected  Entities:  All 


Problem  Statement: 

A postprocessor  can  waste  a lot  of  time  thrashing  the  disk  while 
trying  to  read  an  IGES  file.  The  problem  is  caused  by  the 
Directory  Entry  records  and  Parameter  Data  records  of  an  entity 
being  physically  distant  from  each  other. 

Consider  the  processing  of  a Linear  Dimension  Entity  (216) . The 
lines  which  contain  the  DE  are  read  into  a system  I/O  buffer 
(from  2K  to  8K  in  length) . Reading  the  lines  of  the  associated 
PD  record  will  almost  certainly  over-write  the  I/O  buffer.  These 
lines  contain  pointers  to  DE  lines  that  were  probably  already  in 
the  buffer  that  just  got  over-written.  Similarly,  reading  the 
next  DE  will  over-write  PD  records  of  the  subordinate  entities 
that  were  read  into  the  buffer  along  with  the  parent's  PD  record. 
Worst  case  (all  pointers  non-zero)  implies  twelve  (12)  physical 
reads  of  the  disk,  and  the  postprocessor  will  probably  get 
swapped-out  while  waiting  for  the  I/O. 


Selected  Methodology: 

The  postprocessor  could  open  the  IGES  file  with  two  (2)  logical 
unit  numbers;  one  for  reading  DE  lines,  and  one  for  reading  PD 
lines.  The  system  will  assign  each  its  own  I/O  buffer,  thus 
avoiding  the  over-write  problem.  Since  there  will  be  fewer 
physical  reads,  the  translator  should  stay  in-core  for  longer 
periods  of  time,  and  the  translation  should  proceed  much  faster. 
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RP  38:  UNIQUE  SUBFIGURE  NAMES 


Category:  Software  Practice  IGES  Dociment  Version:  All 

Keywords:  Subfigure  Affected  Processors:  Both 

Affected  Entities: 

Subfigure  Def.  (308) 
Network  Subf.  Def.  (320) 


Problem  Statement: 

Three  variables  in  the  IGES  definition  of  subfigures  may  cause 
problems  when  exchanging  data.  First,  IGES  does  not  specify  a 
naming  convention  for  subfigures  (PD  field  2 of  entities  308  and 
320) . Second,  IGES  does  not  require  that  a subfigure  definition 
only  appear  once  in  any  IGES  file.  Third,  every  CAD/ CAM  system 
has  its  own  unique  naming  conventions  for  subfigures,  and  it 
cannot  be  assumed  that  a receiving  system  can  attach  any 
significance  to  these  names. 

Combined,  it  is  possible  for  a postprocessor  that  wants  to  use 
the  name  of  the  subfigure,  but  only  recognizes  the  first  six 
characters,  to  misinterpret  the  information  and  either  (a) 
process  one  definition  and  ignore  another,  or  (b)  process  a 
definition  and  then  overwrite  it  with  a different  definition. 


Alternatives  Considered: 

1.  The  preprocessor  shall  use  a naming  convention  that 
makes  each  subfigure  name  unique  within  an  IGES  file. 
Upper-  and  lower-case  characters  shall  not  be  mixed, 
and  symbols  represented  by  the  ASCII  values  0-37  Octal 
shall  not  be  used  at  all.  The  naming  convention  will 
provide  uniqueness  in  the  first  six  characters. 

The  postprocessors  shall  process  every  subfigure  in  the 
IGES  file.  If  it  requires  a unique  name  for  the 
subfigure,  then  it  shall  check  that  the  name  has  not 
been  used  before.  If  the  name  is  a duplicate,  then  the 
system  may  respond  in  one  of  three  ways: 

a.  Ignore  the  definition  and  inform  the  user  of  the 
action. 
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b.  Change  the  name  automatically  and  inform  the  user 
of  the  action. 

c.  Ask  the  user  what  to  do. 

2 . The  preprocessor  can  use  any  naming  convention  that  it 
desires,  but  it  shall  only  create  one  uniquely  named 
IGES  subfigure  definition  for  each  subfigure  defined  in 
the  model. 

The  postprocessor  shall  always  assume  that  every 
subfigure  definition  in  the  IGES  file  is  unique  to  that 
file,  and  must  be  processed  to  capture  all  required 
information.  The  postprocessor  shall  provide  a 
mechanism  to  make  the  subfigures  just  processed  unique 
to  the  model  created  from  the  IGES  file,  such  as 
mapping  unrecognized  characters  to  recognizable 
characters . 


Selected  Methodology: 

Alternative  2 is  the  most  accommodating  approach.  In  both 
alternatives,  the  idea  is  to  create  subfigures  that  belong 
strictly  to  one  IGES  file  at  a time.  Therefore,  it  is  better  not 
to  restrict  the  preprocessor  because  there  might  still  be 
conflicts  between  naming  conventions  on  different  systems.  It 
also  puts  less  of  a burden  on  the  postprocessor  as  it  does  not 
have  to  assume  that  the  subfigure  might  already  exist  on  the 
system  and  check  for  it. 
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RP  39:  EMPTY  SUBFIGURES  USED  AS  EXTERNAL  REFERENCES 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords : Subf igur e 

Required  Pointers 


Affected  Processors:  Both 


Affected  Entities 


Subfigure  Def.  (308) 


Problem  Statement: 

Some  IGES  preprocessors  are  creating  "empty”  Subfigure 
Definitions  (308),  i.e.,  Parameter  Data  field  3 (number  of 
entities  in  definition)  is  zero.  This  should  not  be  confused  with 
subfigure  definitions  that  consist  exclusively  of  entities  which 
are  not  supported  by  the  postprocessor. 

In  some  cases,  the  purpose  is  to  exchange  library  subfigures, 
with  the  expectation  that  a subfigure  definition  with  no  pointers 
causes  the  postprocessor  to  check  for  geometry  already  in  the 
system  under  the  same  name.  This  can  cause  problems  for 
postprocessors  not  recognizing  this  mechanism.  The  postprocessor 
may  abort,  or  subsequent  attempts  to  manipulate  the  translated 
data  may  cause  fatal  errors. 

This  is  an  incomplete  IGES  file,  and  is  an  unacceptable 
alternative  to  the  External  File  Reference  mechanism  for  passing 
library  subfigure  data. 


Selected  Methodology: 

Exchange  library  subfigures  using  the  External  File  Reference 
Entities  and  not  through  empty  subfigures. 
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RP  40:  SCALE  IN  MATRIX 


Category:  Software  Practice 
Keywords:  Transform.  Matrix 

Transform.  Matrix  (124) 


ICES  Document  Version:  All 
Affected  Processor:  Pre 
Affected  Entities: 


Problem  Statement: 

Some  preprocessors  have  tried  to  convey  the  scale  of  an  entity 
by  embedding  it  in  the  coefficients  of  the  entity's 
Transformation  Matrix  (124) . This  has  been  seen  in  the  case  of 
the  Subfigure  Instance  (408)  and  View  (410) , neither  of  which  are 
"geometric"  entities.  This  probably  is  a consequence  of  the 
system's  internal  data  representation;  the  determinant  of  such  a 
matrix  is  equal  to  the  scale,  and  it  saves  the  four  (or  eight) 
bytes  of  an  extra  floating  point  number. 


Selected  Methodology: 

Scale  factor  cannot  legally  be  placed  in  the  Transformation 
Matrix  (124) . 

Multiplying  the  coefficients  of  a Transformation  Matrix  by  a 
scaling  factor  is  a violation  of  the  Specification,  which  states 
that  the  determinant  of  a form  0 or  form  1 matrix  (associated 
with  geometry  entities)  must  be  either  positive  one  or  negative 
one,  and  that  the  columns  constitute  unit  vectors. 

Scale  factor  for  the  Subfigure  Instance  (408)  and  View  (410)  must 
be  placed  in  the  explicit  scale  field. 
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RP  41:  ENTITY  IDENTIFIERS 


Category:  Software  Practice 


I6ES  Document  Version:  All 


Keywords:  Names 


Affected  Processor:  Both 


Affected  Entities:  All 


Problem  Statement: 

Passing  of  entity  identifier  information  between  systems  is 
confusing.  Entity  identifiers  also  are  known  as  entity  tags, 
names,  or  labels.  The  concept  of  identifiers  allows  users  to 
identify  entities  in  the  sending  system  and  to  track  them  in  the 
receiving  system.  IGES  has  the  following  methods: 

o Name  in  PD  section  (subfigure  definition  & network 
subfigure  definition) 

o DE  label  & subscript  fields 

o Name  property 

The  name  property  was  added  to  IGES  because  the  DE  fields  were 
too  restrictive  in  size.  The  subscript  field  can  contain  only 
numbers  (length  8)  and  the  label  field  can  contain  alphanumeric 
data  (length  8)  . The  name  property  is  unrestricted  but  adds  a 
great  deal  of  size  to  the  file  because  it  is  a separate  entity. 
The  character  string  is  the  only  useful  piece  of  information. 

The  other  problem  has  to  do  with  uniqueness.  Originally,  many 
CAD  systems  did  not  allow  the  users  to  tag  entities  so 
preprocessors  created  unique  tags.  These  unique  tags  did  not 
help  users  know  what  native  element  in  the  original  system  became 
what  entity  in  the  receiving  system.  It  also  is  not  reasonable 
to  keep  uniqueness  if  there  is  a one-to-many  mapping  when  the 
purpose  is  to  track  entities  through  multiple  translations.  In 
any  event,  IGES  does  not  require  uniqueness;  therefore,  it  should 
not  be  assumed. 


Alternatives  Considered: 

1.  For  subfigures,  use  PD  parameters;  for  all  other 
entities,  use  the  name  property  and  not  the  DE  fields. 
This  alternative  would  specify  only  one  method  for  any 
entity  type,  but  would  increase  file  size. 

2.  Fill  in  the  fields  in  a specified  order,  using  only  one 
method  for  a particular  entity. 
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Preprocessor  Order: 

a.  For  subfigures,  use  PD  parameters. 

b.  For  all  other  entities,  if  the  label  fits  into  the 
DE  fields,  use  those. 

c.  If  not,  use  the  name  property. 

Postprocessor  Order:  The  order  is  different  from  the 
preprocessor,  as  both  the  name  property  and  DE  fields  may 
exist.  If  they  both  exist,  it  is  reasonable  to  assume  the 
name  property  is  the  more  accurate  data. 

a.  For  subfigures,  use  PD  parameters. 

b.  Use  the  name  property  if  it  exists. 

c.  Use  the  DE  fields. 


Selected  Methodology: 

Use  method  2.  This  is  the  most  complex,  but  it  is  efficient  in 
terms  of  file  storage  while  still  allowing  complete  flexibility 
in  name  length. 

Postprocessors  must  also  handle  non-unique  names  as  uniqueness 
is  not  required  by  IGES. 
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RP  42:  UNIQUE  NAMES 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Names,  Subfigures 


Affected  Processor:  Post 


Affected  Entities 


Subfigure  Def.  (308) 


Network  Subf.  Def.  (320) 


Name  Prop.  (406,  form  15) 


Problem  Statement: 

IGES  files  contain  names  such  as  the  Subfigure  Definition  (308) 
and  the  Name  Property  (406,  form  15)  . Many  operating  systems  and 
applications  have  restrictions  on  what  constitutes  a valid  name 
for  files  and  internal  names,  but  IGES  does  not  contain  any 
restrictions.  Examples  of  system  dependent  restrictions  are: 

Names  restricted  to  seven  characters; 

Names  cannot  contain  underscores  or  special  characters; 

Names  must  be  unique. 


Selected  Methodology: 

Postprocessors  should  be  aware  of  restrictions  and  should 
implement  a substitution  or  mapping  algorithm  to  convert  invalid 
names  to  valid  names. 


Rationale: 

Preprocessors  can't  be  restricted  to  all  possible  restrictions 
for  postprocessors.  Postprocessors  must  be  robust  enough  to  map 
all  names. 
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RP  43:  CLOSED  AREAS 


Category:  Software  Practice 
Keywords:  Closed  Areas 


ICES  DocTiment  Version:  All 
Affected  Processor:  Pre 
Affected  Entities: 

Copious  Data  (106) 
Sectioned  Area  (230) 


Problem  Statement: 

Preprocessors  use  Copious  Data  Entities  (106,  form  11)  to  create 
closed  areas  such  as  curves  which  are  referenced  by  the  Sectioned 
Area  Entity  (230) . 


Selected  Methodology: 

Preprocessors  should  use  Copious  Data  Entities  (106,  form  63)  to 
create  closed  areas. 


Rationale: 

Entity  Type  106,  form  63  includes  a function  that  is  lost  with 
the  form  11  since  form  63  says  it  is  closed  and  form  11  does  not. 
The  Entity  Type  230  must  point  to  geometry  which  is  closed. 
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RP  44:  TEXT  BOX  PROCESSING 


Category:  Software  Practice  IGES  Dociiment  Version:  All 

Keywords:  Text  Affected  Processor:  Post 

Affected  Entities: 

General  Note  (212) 


Problem  Statement: 

Systems  having  fixed  aspect  ratios  for  their  text  have 
difficulties  creating  a text  string  that  stays  within  the  box 
height  and  width  defined  by  the  IGES  212  entity  (see  Figure  1) . 
This  problem  can  cause  the  text  to  overwrite  surrounding  geometry 
or  text.  (Systems  with  variable  aspect  ratio  text  do  not  have 
this  problem  and  may  disregard  this  recommended  practice.) 


Alternatives  Considered: 

Three  methods  can  be  used  to  create  text  on  systems  with  fixed 
text  aspect  ratios: 

1.  Use  both  the  box  height  and  width  from  the 
IGES  212  entity  and  adjust  text  to  maintain 
both  height  and  width  (see  Figure  1) . 

2.  Use  the  defined  box  width  from  the  General 
Note  Entity  (212)  for  the  text  width.  This 
usually  will  result  in  text  looking  like 
Figure  3 , but  can  sometimes  result  in  the 
string  exceeding  the  IGES  box  height. 

3.  Use  the  defined  box  height  from  the  IGES  212 
entity  for  the  text  height.  This  usually  will 
result  in  the  string  exceeding  the  IGES  box 
width  (see  Figure  2) . 
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FIGURE  1 


FIGURE  3 
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Selected  Methodology 


Recommended  Practices  usually  suggest  only  one  way  to  process  a 
particular  portion  of  an  entity.  However,  it  was  brought  to  the 
attention  of  the  Recommended  Practices  Committee  that  different 
applications  require  different  results.  Implementors  should  study 
the  applications  being  performed  on  their  systems  and  should 
apply  the  appropriate  method  from  above. 

a.  If  more  than  one  application  is  running  on  a particular 
system,  an  option  should  be  made  available  which  allows  the  user 
to  choose  the  desired  method. 

b.  If  a switch  cannot  be  provided,  the  order  using  the 
above  methods  should  be: 

Method  1.  Define  text  within  the  box 
(Figure  4) 

Method  2.  Define  text  within  the  width  of  the  box 
(Figure  3) 

Method  3.  Define  text  within  the  height  of  the  box 
(Figure  2) 
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RP  45:  NULL  TEXT  STRING 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords : Text 


Affected  Processor:  Both 


General  Note 


Affected  Entities 


Null  String 


General  Note  (212) 


Problem  Statement: 

Prior  to  IGES  5.0,  the  null  string  was  not  defined.  The  number 
of  characters  in  a Hollerith  string  must  be  greater  than  zero; 
therefore,  '*0H,**  is  an  invalid  Hollerith  string  parameter. 


Alternatives  Considered: 

1.  Define  the  null  string  as  one  blank  character  (i.e., 
**1H  ,**)  . 

2.  Define  the  null  string  as  a default  parameter  (i.e.. 

Most  postprocessors  cannot  recognize  a 
defaulted  string  parameter  value. 


Selected  Methodology: 

Preprocessors  should  write  the  null  string  as  **,,'*. 

Postprocessors  should  interpret  a General  Note  Entity  (212)  with 
one  string,  where  the  string  is  either  one  blank  text  string  (**1H 
,”)  or  a default  parameter  ('*,,**),  as  a null  string. 
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RP  46:  DRAFTING  SYMBOLS 


Category:  Software  Practice 


IGES  Document  Version:  All 


Keywords:  Text 


Affected  Processor:  Pre 


General  Note 


Affected  Entities 


Drafting  Symbols 


General  Note  (212) 


General  Symbol  (228) 


Problem  Statement: 

ANSI  Y14.5  drafting  symbols  have  fixed  aspect  ratios,  and  their 
widths  do  not  correspond  to  normal  ASCII  alphanumeric  characters. 
In  the  exchange  of  the  General  Symbol  Entity  (228)  , there  are 
alignment  problems  when  the  symbols  are  used  in  the  same  strings 
with  alphanumerics . 


Selected  Methodology: 

Font  Characteristics  (FC)  1001,  1002,  and  1003  contain  both  ANSI 
and  non-ANSI  special  symbols.  (Examples  of  non-ANSI  symbols  are 

Greek  letters  such  as  ”pi”.) 

When  ANSI  non-alphanumeric  symbols  are  used  in  General  Notes 
(212)  , they  should  be  used  in  strings  of  a single  character,  with 
a width  as  specified  in  ANSI  Y14.5M-1982,  Dimensioning  and 
Tolerancing. 
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APPENDIX  A.  PROPOSED  RECOMMENDED  PRACTICES  FORM 


PRP Rev 

Page  1 of  _ 

Date 


INITIAL  GRAPHICS  EXCHANGE  SPECIFICATION 


PROPOSED  RECOMMENDED  PRACTICE 


Author 
Address : 


Phone : 


Ext. 


Category : 

Keywords: Affected  Processors:  Pre/Post 

Affected  Entities: 


Topic : 

Problem  Statement: 
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PRP__ 

Page 


INITIAL  GRAPHICS  EXCHANGE  SPECIFICATION 
PROPOSED  RECOMMENDED  PRACTICE  (cont.) 


Rev 

of 
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APPENDIX  B.  CHANGE  ORDERS  FOR  IGES  VERSION  5.0 


The  following  Edit  Change  Orders  (ECOs)  to  IGES  Version  4.0  were 
approved  by  the  IGES  RFC  Review  Committee  and  were  incorporated 
into  IGES  Version  5.0  when  it  was  published  in  October,  1990. 
They  are  summarized  here  for  the  benefit  of  those  who  may  not 
have  been  aware  of  them.  For  a copy  of  the  complete  ECO,  contact 
the  IPO  Chairman,  National  Institute  of  Standards  and  Technology, 
Bldg.  220,  Rm.  A127,  Gaithersburg,  MD,  20899. 


E500  (RFC  361A) 

FILE  BLANK  LINES  - Specifies  that  IGES  files 
may  have  trailing  blank  lines  (e.g.,  to  pad 
a disk  block) , but  no  leading  blank  lines. 

E501  (RFC  375) 

PIECEWISE-COPIOUS  PARAMETRIZATION  - Provides 
parametrizations  for  the  Copious  Data  Entity 
(Type  106,  Forms  11  & 12) . 

E502  (RFC  387B) 

NULL  POINTERS  - Clarifies  situations  in  which 
defaulted  or  "null”  pointers  can  be  used. 

E503  (RFC  394) 

PROCESS  PLANT  ATTRIBUTES  - Adds  predefined 
values  to  the  Attribute  Table  Definition 
Entity  (Type  322) . 

E504  (RFC  358) 

LINE  FONT  0 - Adds  a "no  line  font  specified” 
value,  analogous  to  the  "no  color  specified” 
value. 

E505  (RFC  373A) 

CSG  DISJOINT  COMPONENTS  - Creates  a Selected 
Component  Entity  (Type  182)  for  use  in  CSG 
applications . 

E506  (RFC  380) 

EXTENDED  VIEWS  VISIBLE  - Creates  a new  Form 
of  the  Associativity  Instance  (Type  402,  Form 
19)  to  indicate  view  visibility,  color,  and 
line-style  of  curves  based  on 
parameterization . 

E507  (RFC  283C) 

PERSPECTIVE  VIEW  - Creates  a new  Form  of  the 
View  Entity  (Type  410,  Form  1)  to  transfer 
perspective  views  in  a form  similar  to  the 
presentation  methodology  of  PHIGS. 

E508  (RFC  340A) 

REDUNDANT  EXTERNAL  REFERENCE  - Deprecates  the 
External  Logical  Reference  File  Index 
Associativity  Entity  (Type  402,  Form  2). 
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E509  (RFC 

E510  (RFC 

E511  (RFC 

E512  (RFC 

E513  (RFC 

E514  (RFC 

E515  (RFC 

E516  (RFC 

E517  (RFC 

E518  (RFC 
E519  (RFC 

E520  (RFC 


369A) 

374) 

379D) 

381/382) 

383) 

384) 

388) 

392) 

398) 

399) 

404) 

413) 


PATTERN  HATCH  ENTITY  - Defines  new  area  fill 
pattern  codes  for  the  Sectioned  Area  Entity 
(Type  230)  to  support  AEC  applications. 

COMPOSITE  COPIOUS  REFERENCE  - The  Composite 
Curve  Entity  (Type  102)  may  now  reference  a 
Copious  Data  Entity  (Type  106) . 

BOUNDED  SURFACE  - Creates  a new  Bounded 
Surface  Entity  (Type  143)  and  a new  Boundary 
Entity  (Type  141) . 

LINEAR  DIMENSION  EXTENSIONS  - Adds  new  Forms 
to  the  Linear  Dimension  Entity  (Type  216)  to 
indicate  use  as  a Diameter  Dimension  (Form  1) 
or  a Radius  Dimension  (Form  2) . 

GENERAL  SYMBOL  LEADER  - Clarifies  the  use  of 
the  Witness  Line  Entity  (Type  106,  Form  40) 
and  Leader/Arrow  Entity  (Type  214)  in 
connection  with  the  General  Symbol  Entity 
(Type  228,  Forms  1 & 3) . 

GENERAL  SYMBOL  USER  FORM  - Reserves 
implementor-defined  Form  Numbers  for  the 
General  Symbol  Entity  (Type  228) . 

FEM  ELEMENT  ADDITION  - Five  new  topology 
types  are  added  to  the  Finite  Element  Entity 
(Type  136) . 

PLANE/SINGLE  PARENT  - Deprecates  the  use  of 
the  Single  Parent  Associativity  (Type  402, 
Form  9)  to  create  holes  in  bounded  planar 
regions. 

COMPRESSED  ASCII  REVISION  - Revised 
definition  of  the  Compressed  ASCII  Format  for 
IGES  files. 

TERMINATE  REVISION  - Revised  definition  of 
the  Terminate  Section. 

MATRIX  ORDER  - Corrects  explanation  of 
intended  operation  of  explicitly  nested 
Transformation  Matrix  Entities  (Type  124)  . 

POINT  DIMENSION  EXTENSION  - Allows  the  Point 
Dimension  Entity  (Type  220)  to  reference  a 
Simple  Closed  Planar  Curve  Entity  (Type  106, 
Form  63) . 
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E521  (RFC  418) 

VIEWS  VISIBLE  ENTITY  COUNTS  - The  pointers 
to  entities  which  are  affected  by  the  Views 
Visible  Associativity  Entities  (Type  402, 
Forms  3 & 4)  are  no  longer  required;  for 
backward  compatibility,  they  are  optional. 

E522  (RFC  419A) 

B-SPLINE  WEIGHTS  - Clarifies  the  definition 
of  a rational  B-spline. 

E523  (RFC  425) 

SPICE  PARAMETERS  - Adds  predefined  attributes 
for  electrical  applications  to  the  Attribute 
Table  Definition  Entity  (Type  322) . 

E524  (RFC  428) 

COMPOSITE  CURVE  RESTRICTIONS  - Clarifies  a 
special  case  of  the  Composite  Curve  Entity 
(Type  102)  in  regards  to  the  Connect  Point 
Entity  (Type  132) . 

E525  (RFC  429) 

SIMPLE  CLOSED  CURVE  - Adds  a definition  of  a 
Simple  Closed  Curve  to  the  Glossary. 

E526  (RFC  430) 

106/63  CLARIFICATION  - The  Simple  Closed  Area 
Entity  (Type  106,  Form  63)  has  been  renamed 
Simple  Closed  Planar  Curve. 

E527  (RFC  389) 

TABULAR  DATA  PTYPE=12  - Clarifies  Nodal 
Loads/Constraint  Data  in  the  Tabular  Data 
Form  of  the  Property  Entity  (Type  406,  Form 
11)  . 

E528  (RFC  390) 

UNITS  DATA  ENTITY  - Creates  a Units  Data 
Entity  (Type  316)  for  use  in  FEM 
applications. 

E529  (RFC  335) 

BINARY  TO  APPENDIX  - Deprecates  the  Binary 
Format  for  IGES  files. 

E530  (RFC  370C) 

PREDEFINED  LINE  FONT  PATTERNS  - Creates  a new 
Form  of  the  Property  Entity  (Type  406,  Form 
19)  to  identify  AEC  line  font  patterns. 

E531  (RFC  414A) 

8-BIT  ASCII  - Clarifies  the  prohibition 
against  8-bit  ASCII  characters  in  IGES  files. 

E532  (RFC  432A) 

USER/ IMPLEMENTOR  DEFINED  - Changes  all 
references  of  "user  defined”  to  "implementor 
defined” . 

E533  (RFC  436) 

VIEW  CLIPPING  PLANES  - Permits  use  of  the 
Unbounded  Plane  Entity  (Type  108,  Form  0)  for 
clipping  planes  referenced  by  a View  Entity 
(Type  410) . 
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E534  (RFC  377B) 

HIGHLIGHT  AND  PICK  PROPERTIES  - Creates  two 
new  Forms  of  the  Property  Entity  (Type  406, 
Forms  20  & 21)  to  communicate  "highlight”  and 
"pick" . 

E535  (RFC  316) 

DIMENSION  ORIGIN  LEADER  (214/12)  - Creates  a 
new  arrowhead  style  for  the  Leader  (Arrow) 
Entity  (Type  214) . 

E536  (RFC  372) 

B-REP  SURFACES  - Creates  new  entities  for 
Boundary  Representation  (B-REP)  surfaces. 
(This  ECO  was  canceled  by  E587.) 

E537  (RFC  376) 

UNIFORM  RECTANGULAR  GRID  PROPERTY  (406/22)  - 
Creates  a new  Form  of  the  Property  Entity 
(Type  406)  to  exchange  rectangular  grids  on 
drawing  sheets. 

E538  (RFC  378B) 

DRAWING  WITH  ROTATED  VIEWS  (404/1)  - Creates 
a new  Form  of  the  Drawing  Entity  (Type  404) 
to  exchange  drawings  with  rotated  views. 

E539  (RFC  406) 

APPENDIX  SAMPLE  FILE  - Replaces  the 
Electrical  Part  Sample  file  in  Appendix  A of 
the  Specification  with  the  file  from  the 
Electrical  Application  Guide. 

E540  (RFC  431) 

NULL  STRING  - Adds  an  entry  to  the  Glossary 
Appendix  to  define  the  Null  String. 

E541  (RFC  440) 

NEW  ORDINATE  DIM  FORM  # (218/1)  - Creates  a 
new  Form  for  the  Ordinate  Dimension  (Type 
218)  containing  both  a Witness  Line  and  a 
Leader  (Arrow) . 

E542  (RFC  442) 

CONNECT  POINTS  IN  NETWORK  SUBFIGURES  - 
Creates  an  explicit  linkage  between  the 
Connect  Point  entities  (Type  132)  in  a 
Network  Subfigure  Definition  entity  (Type 
320)  and  the  Network  Subfigure  Instance 
entities  (Type  420)  which  reference  it. 

E543  (RFC  445A) 

STANDARD  BLOCK  FONT  - Changes  the  name  of 
font  characteristic  (FC)  1 in  the  General 
Note  Entity  (Type  212) . 

E544  (RFC  446) 

GLOBAL  PARAMETER  16  DEFAULT  - Provides  a 
default  value  for  Global  Parameter  16 
(Maximum  Number  of  Line  Weight  Gradations) . 

E545  (RFC  448) 

RENAME  GLOBAL  PARAMETER  17  - Changes  the  name 
of  Global  Parameter  17  from  "Size  of  maximum 
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line  width” 
weight” . 


to  "Width  of  maximum  line 


E546  (RFC  395A) 

CONNECTIVITY  DEFAULT  POINTERS  - Clarifies  the 
descriptions  of  certain  pointers  in  Entity 
Types  132,  320,  and  420. 

E547  (RFC  437E) 

KANJI  GENERAL  NOTE  - Adds  support  for  the 
Japanese  national  character  set  (JIS  C 6226- 
1983)  as  a new  font  characteristic  (FC  2001) 
in  the  General  Note  Entity  (Type  212) . 

E548  (RFC  451) 

MACRO  ENTITY  TO  APPENDIX  - Move  the 
definition  of  the  Macro  Entity  (Type  306)  to 
the  Unimplemented  Entities  ("Gray  Page”) 
Appendix. 

E549  (RFC  454) 

PLACEMENT  OF  DRAFTING  SYMBOLS  - Adds  a figure 
giving  examples  of  text-height  and  text -width 
as  it  applies  to  the  display  of  drafting 
symbols  defined  in  ANSI  Y14.5M-1982 
Dimensioning  and  Tolerancing. 

E550  (N/A) 

ERRATA  FROM  VERSION  4.0  - (editorial 
tracking)  The  IGES  Editor  is  directed  to  add 
the  errata  for  IGES  Version  4.0  to  the 
Working  Draft  for  the  next  version. 

E551  (N/A) 

REORGANIZE  AND  ORDER  ENTITIES  - (editorial 
tracking)  The  IGES  Editor  is  directed  to 
reorganize  the  Working  Draft  of  the  next 
version  as  needed  to  accomplish  the  goal  of 
listing  the  entity  definitions  in  ascending 
order  by  Entity  Type  Number. 

E552  (N/A) 

CONSISTENCY  OF  PD  SUBSECTIONS  - (editorial 
tracking)  The  IGES  Editor  is  directed  to  make 
consistent  appearance  of  vertical  dots,  the 
phrase  "or  zero”,  and  the  phrase  "Pointer  to 
the  DE  of  the  ...”  in  the  PD  subsections  of 
each  entity  definition. 

E553  (N/A) 

CORRECTIONS  TO  EXAMPLE  PART  FILE  - (editorial 
tracking)  The  IGES  Editor  is  directed  to  add 
a corrected  version  of  the  Appendix  A Example 
3 IGES  file  (Drawing  and  View  Example) . 

E554  (N/A)  ' 

CHANGE  BARS  - (editorial  tracking)  The  IGES 
Editor  is  directed  to  devise  a practical 
method  of  indicating  ECO  changes  since 
Version  4.0  of  the  Specification. 
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E555  (N/A) 

REMOVE  SUBSECTION  NUMBERS  ON  DE  & PD  - 
(editorial  tracking)  The  IGES  Editor  is 
directed  to  remove  the  subsection  numbers 
from  DE  and  PD  descriptions  in  the  entity 
definitions. 

E556  (N/A) 

CORRECT  FIGURE  78  - (editorial  tracking) 
Figure  78  is  moved  to  the  Grey  Page  Appendix 
and  replaced  by  a correct  figure. 

E557  (N/A) 

PARAMETRIC  SPLINE  CURVE  - (editorial 
tracking)  An  error  occurred  in  transcribing 
Version  3 to  Version  4;  in  Section  3.8  (page 
91) , in  the  sentence  that  begins  "In  order  to 
avoid  degeneracy,  the  phrase,  "...  must 
be  zero:"  should  be,  "...  must  be  nonzero:". 

E558  (N/A) 

AMEND  ECO  506  (EXTENDED  VIEWS  VISIBLE)  - 
(editorial  tracking)  In  section  4.3.11  (page 
339)  , in  the  last  paragraph,  change  the 
phrase,  "(Type  402,  Form  3 or  4)"  to  "(Type 
402,  Form  3,  4,  or  19)". 

E559  (N/A) 

PARAMETER  DATA  LISTS  - (editorial  tracking) 
Corrects  the  Parameter  Data  Lists  of  a few 
entities  for  editorial  consistency. 

E560  (N/A) 

AMEND  ECO  511  (BOUNDED  SURFACE)  - (editorial 
tracking)  Several  of  the  parameter  names  for 
Entity  Types  141  and  143  were  confusing. 

E561  (N/A) 

MOVE  TYPES  322  & 422  FROM  GRAY  PAGES  TO  BODY 
(editorial  tracking)  The  material  for 
Entity  Types  322  (Attribute  Table  Definition) 
and  422  (Attribute  Table  Instance)  is  moved 
from  Appendices  J.8  and  J.9  into  the 
appropriate  locations  in  the  body  of  the 
Specification. 

E562  (N/A) 

MOVE  FC  1003  FROM  GRAY  PAGES  TO  BODY  - 
(editorial  tracking)  The  material  for  Font 
1003  (Drafting  Font)  is  moved  from  Appendix 
J.5  into  Section  4.2.9  General  Note  Entity 
(Type  212).  ' 

E563  (N/A) 

APPENDIX  SAMPLE  FILE  (A. 2)  - (editorial 

tracking)  In  the  Mechanical  Part  Example 
(Appendix  A,  Example  2)  the  setting  of  the 
Hierarchy  Flag  on  some  of  the  dimensions 
caused  several  postprocessors  to  produce 
incorrect  results. 
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E564  (RFC  189B) 

POINT  PARAMETER  4 - In  the  Point  Entity  (Type 
116)  , parameter  index  4 (PTR)  is  changed  from 
"subfigure  instance"  to  "subfigure 
definition. " 

E565  (RFC  256B) 

MODEL  DATE/TIME  STAMP  - A new  parameter  is 
added  to  the  Global  Section  to  record  the 
date/time  of  the  native  model's  creation  or 
last  modification. 

E566  (RFC  386C) 

CURVE  DIMENSION  ENTITY  (204)  - Creates  a new 
Curve  Dimension  Entity  (Type  204)  for  use  in 
drafting  applications. 

E567  (RFC  405E) 

IMPROVED  GENERAL  NOTE  (213)  - Creates  a New 
General  Note  Entity  (Type  213)  for  the 
representation  of  text  strings,  as  an 
alternative  to  the  Type  212. 

E568  (RFC  407B) 

CONFORMANCE  RULES  - A definition  of 

conformance  is  added  to  the  specification. 

E569  (RFC  416B) 

SECTIONED  AREA  ENTITY  (230/0)  - Clarifies  the 
definition  of  the  Sectioned  Area  Entity  (Type 
230,  Form  0) . 

E570  (RFC  447A) 

NEW  230  FORM  NUMBER  (230/1)  - Creates  a new 
Form  Number  of  the  Sectioned  Area  Entity 
(Type  230/1)  for  Inverted  Crosshatching. 

E571  (RFC  450A) 

ASSOCIATIVITY  GROUP  TYPE  PROPERTY  (406/23)  - 
Creates  a new  Form  Number  of  the  Property 
Entity  (Type  4 06,  Form  23)  for  naming  Group 
Associativities . 

E572  (RFC  452) 

NEW  EXTERNAL  REFERENCE  FORM  NUMBER  (416/3)  - 
Creates  a new  Form  Number  of  the  External 
Reference  Entity  (Type  416,  Form  3)  for 
referencing  native  parts  instead  of  IGES 
files . 

E573  (RFC  455A) 

LEVEL  TO  PWB  LAYER  MAP  (406/24)  - Creates  a 
new  Form  Number  of  the  Property  Entity  (Type 
406,  Form  24)  for  mapping  exchange  file 
levels  to  Printed  Wire  Board  layers. 

E574  (RFC  459A) 

PWB  ARTWORK  STACKUP  (406/25)  - Creates  a new 
Form  Number  of  the  Property  Entity  (Type  406, 
Form  25)  for  representing  Printed  Wire  Board 
Artwork . 
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E575  (RFC  461A) 

PWB  DRILLED  HOLE  (406/26)  - Creates  a new 

Form  Number  of  the  Property  Entity  (Type 

406,  Form  26)  for  representing  drilled  holes 
in  Printed  Wire  Boards. 

E576  (RFC  462A) 

CONNECT  POINT  EXTENSION  - Adds  new  Pin  Type 
and  Pin  Function  values  to  the  Connect  Point 
Entity  (Type  132) . 

E577  (RFC  464A) 

REGION  RESTRICTION  EXTENSION  - Adds  new 
constraints  to  the  Region  Restriction 
Property  (Type  406,  Form  2) . 

E578  (RFC  465A) 

PWA  MANUFACTURING  ATTRIBUTES  - Adds  a new 
Attribute  List  Type  (ALT=5)  to  the  Attribute 
Table  Definition  Entity  (Type  322)  for 
Electrical  and  Printed  Wire  Assembly 
Manufacturing . 

E579  (RFC  469A) 

GENERAL  NOTE  TEXT  BOX  - Removes  the 
requirement  that  text  box  height  be  preserved 
by  postprocessors. 

E580  (RFC  473A/478) 

DE  REQUIREMENTS  - Removes  Table  3 and  places 
the  DE  requirements  for  each  entity  along 
with  its  PD  description. 

E581  (RFC  477A) 

CHANGE  ENTITY  TYPE  NUMBERS  - Changes  several 
of  the  Entity  Type  Numbers  assigned  by 
previous  Edit  Change  Orders. 

E582  (RFC  479A) 

B-SPLINE  CLOSURE  PROPERTY  - Clarifies  the 
term  "closed"  for  Rational  B-spline  Curves 
(Type  126)  and  Rational  B-spline  Surfaces 
(Type  128) . 

E583  (N/A) 

MOVE  NULL  ENTITY  FROM  GRAY  PAGES  - (editorial 
tracking)  The  material  for  the  Null  Entity 
(Type  0)  is  moved  from  Appendix  J.2  into  the 
body  of  the  Specification. 

E584  (N/A) 

MOVE  214/12  ENTITY  FROM  GRAY  PAGES  - 
(editorial  tracking)  The  material  for  the 
Dimension  Origin  arrowhead  style  (Type  214, 
Form  12)  is  moved  from  Appendix  J into  the 
body  of  the  Specification. 

E585  (N/A) 

DELETE  APPENDICES  C & D (editorial  tracking) 
The  material  in  Appendices  C (Plant  Flowsheet 
Representation)  and  D (Piping  Model  Example) 
is  removed  from  the  Specification. 
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E586  (N/A) 

DELETE  APPENDIX  B - (editorial  tracking)  The 
material  in  Appendix  B (Electrical/Electronic 
Product  Representation)  is  removed  from  the 
Specification. 

E587  (N/A) 

DEPRECATE  ECO  536  (B-REP  SURFACES) 

(editorial  tracking)  ECO  536  is  cancelled; 
the  material  must  be  reballoted  as  an  RFC. 

E588  (N/A) 

CONFORMANCE  RULES  CORRECTION  - ECO  568 
contained  the  incorrect  text;  it  was  the  text 
as  balloted,  not  as  amended  by  the  ballot 
review.  This  is  the  correct  text,  and  this 
ECO  supersedes  ECO  568. 

E589  (N/A) 

PD  LISTS  FOR  COPIOUS  DATA  (TYPE  106)  - 

Several  ECOs  make  the  current  format  of  the 
various  forms  of  the  Copious  Data  Entity 
(Type  106)  impractical  to  print  as  in 
previous  versions  of  the  Specification. 

E590  (RFC  392) 

AMEND  ECO  516  (PLANE/SINGLE  PARENT)  - ECO  516 
did  not  provide  sufficient  editorial 
instructions  to  preserve  the  upward 
compatibility  of  the  Specification. 

E591  (N/A) 

CLARIFICATION  OF  BOUNDED  PLANES  - In  the 
description  of  the  Plane  Entity  (Type  108)  , 
the  text  is  not  consistent  with  the 
restrictions  on  the  Form  Numbers  and  PD  field 

5. 

E592  (RFC  473) 

AMEND  ECO  580  (DE  REQUIREMENTS)  - DE 
requirements  for  two  of  the  Entity  Types  (134 
and  422)  contained  errors  that  contradicted 
the  text. 
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(214) 

37 
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54 
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67 

(230) 

62 

(306) 

26 

(308) 

6, 

55,  57,  61 

(312) 

49, 

51 

(320) 

55, 

61 

(402, 

forms  3 & 4)  29 

(404) 

49 

(408) 

6, 

49,  52,  58 

(410) 

49 

Annotation  5,  11 

Arrowhead  37,  48,  74,  79 

Blank  Status  5,  47 

Comment  30 

Coordinate  System  18 

DE  Hierarchy  Flag  47 

DE  Level  Number  11,  38 

Default  Value  42-46,  75 

Directory  Entry  5-7,  27,  30,  47,  54 

Documentation  2,  12,  15,  19,  37,  46 

Drafting  Symbols  67 

Drawing  47,  49,  74,  76 

Entity  Mapping  2,  11,  31,  33,  37,  38,  40 

Entity  Origin  49,  52 

Error  Message  12,  13,  19 

Extra  View  18 

Flag  Note  17 

Global  Parameter  8,  10,  24,  25,  35,  42,  43,  53,  75 
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Global  Section  8,  10,  24,  35,  42,  77 
Hierarchy  2,  6,  27,  47,  77 
Hierarchy  Flag  47,  77 
Hierarchy  Rule  2,  6,  27,  47 
Identity  Matrix  7,  49 
IGES  Description  2,  8,  17,  26,  29 
Implementation  Rationale  2 
Index  81 

Information  Message  15,  19 
Invalid  Data  20 
Leader  Line  28,  37 


Level  Number 

11/ 

38, 

47 

MACRO  2 6 , 

75 

Manual  1 , 

2, 

19 

Matrix  6 , 

7, 

18, 

o 

CM 

22,  23,  27,  49-52,  58,  72 

Matrix  Processing  6,  7,  18,  22 

Max.  Coordinate  Value  10,  43 

Minimum  Resolution  35 

Model  Space  Scale  24,  43,  44 

Multiple  Pass  39 

Names  55,  59-61,  76 

Null  String  66,  74 

Number  Format  53 

Origin  49,  52 

PD  26,  30,  54,  55,  59,  60,  75,  76,  78,  80 

PDDI  Report  18,  19,  24,  26,  37 

Performance  iii,  2,  7,  35 

Plane  31,  52,  72,  74,  80 

Required  Pointers  57 

Robustness  12 

Rotation  Angles  51,  52 

Sectioned  Area  Entity  62,  72,  77 

Single  Pass  39 

Slope  Discontinuous  32 

Software  Practice  2,  4,  5,  9,  10,  18,  20,  22,  24,  30,  32, 
39,  42,  48,  49,  51-55,  57-59,  61-63,  66,  67 
Spline  Curve  33,  35,  40,  41,  76 
Spline  Surface  33,  40 
Subfigure  6,  55,  57 
Subord.  Entity  Switch  11,  27 
Summary  Report  15 
System  ID  8,  43 
Tape  Format  9 
Testing  Method  2,  36 

Text  2,  14,  17,  25,  49,  51,  53,  63,  65-67,  75,  77,  78,  80 
Thrashing  54 

Transformation  Matrix  7,  18,  20,  22,  49-52,  58,  72 
View  18,  29,  47,  49,  58,  71,  74,  76 
View  Associativity  29 

Witness  Line  5,  11,  28,  37,  48,  72,  74 
Workaround  2 
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